This article has been accepted for publication in a future issue of this journal, but has not been
fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
IEEE INTERNET OF THINGS JOURNAL
Security Challenges and Opportunities for Smart
Contracts in Internet of Things: A Survey
Kai Peng, Meijun Li, Haojun Huang, Chen Wang, Senior Member, IEEE,
Shaohua Wan, Senior Member, IEEE, and Kim-Kwang Raymond Choo, Senior Member, IEEE
Abstract—Smart contracts, one of the success stories in
blockchain 2.0, have been widely utilized in a broad range of
applications, including those involving Internet of Things (IoT).
Given the fast-pace nature of the topic, it can be challenging for
the research community to keep track of the latest advances.
Hence, in this paper, we perform a comprehensive, in-depth
review of known security challenges (e.g., inherently vulnerable
particularities, programming vulnerabilities, and attacks) and
potential research opportunities associated with the deploying
of smart contracts in an IoT setting. This survey is expected to
serve as a starting point for exploiting the benefits of dependable
smart contracts in this new and largely open area.
Index Terms—Smart contract, Internet of Things, security
auditing, programming vulnerability, blockchain.
I. I NTRODUCTION
The Internet of Things (IoT), which provides a general
network for data exchange and communication between the
things, is leading to a higher level of automation, a more
efficient society and a better life nowadays [1]–[3]. The
traditional IoT industry usually adopts a centralized service
platform, or a distributed platform following some centraliza-
tion principles, for the implementation of productive capabil-
ities and applications. However, with the rapidly increasing
number of devices and demands for services, traditional IoT
architectures are facing enormous challenges of the higher cost
of construction and maintenance of large-scale data centers,
performance bottlenecks and more security and privacy risks
(e.g., cyber-attacks) [4]–[6].
The emergence of blockchain technologies brings hope of
sorting out these issues [7]–[12]. Derived from the famous
cryptocurrency Bitcoin [13], a blockchain is a distributed
ledger with all records appended in an ongoing chain of data
This work was supported in part by the National Natural Science Foundation
of China under Grants 61872416, 62002104, 52031009 and 62071192; by
the Fundamental Research Funds for the Central Universities of China under
Grant 2019kfyXJJS017; by the Natural Science Foundation of Hubei Province
of China under Grant 2019CFB191; and by the Open Research Project of
Hubei Key Laboratory of Intelligent Geo-Information Processing under Grant
KLIGIP-2018A03. (Corresponding author: Chen Wang.)
K. Peng, M. Li, H. Huang and C. Wang are with School of Electronic
Information and Communications, Huazhong University of Science and Tech-
nology, Wuhan 430074, China. K. Peng and C. Wang are also with Hubei
Key Laboratory of Intelligent Geo-Information Processing, China University
of Geosciences, Wuhan 430078, China. Email: {pkhust, meijunli, hjhuang,
chenwang}@hust.edu.cn.
S. Wan is with School of Information and Safety Engineering, Zhongnan
University of Economics and Law, Wuhan 430073, China. Email: shao-
hua.wan@ieee.org.
K.-K. R. Choo is with the Department of Information Systems and Cyber
Security, University of Texas at San Antonio, San Antonio, TX 78249-0631,
USA. Email: raymond.choo@fulbrightmail.org.
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
1
blocks and immutable once being confirmed. It provides a
decentralized, securely encrypted blockchain network for IoT
nodes, making it difficult for hackers to control the entire
network through a single weakness. Thus, it has the potential
to not only address the problems of scalability, trust cost and
small-scale points of failure, but also allow for more intelligent
automation and efficient transactions (without the need of third
parties) [14]–[16].
As promising technology of blockchain 2.0, smart contracts
facilitate more practical applications in the integration between
the blockchain and IoT industry [17]–[21]. As early as 1997,
Nick Szabo formally proposed the concept of a quantitative
electronic trading agreement for the implementation of con-
tract terms [22]. The overall goal of designing smart contracts
is to meet common contractual conditions (e.g., payment
terms, confidentiality, etc.), and to abate malicious or acciden-
tal anomalies and reliance on trusted intermediaries. However,
it is after the emergence of the blockchain technology that
smart contracts are truly implemented [23]. With blockchain
features, a smart contract is able to automatically execute
the agreements prescribed in advance when some triggering
conditions are met. In IoT scenarios, smart contracts enable
peer-to-peer contractual behaviors for IoT devices without
any central authority but the blockchain nodes to certify
the transactions, thus yielding a more efficient management
paradigm with lower cost [24].
Nevertheless, current techniques of smart contracts are still
far from maturity and reliability since the birth of the first
smart contract platform called Ethereum [23] five years ago,
and gradually reveal many vulnerabilities and problems in
recent years [25], [26]. The most notorious accident caused
by smart contracts is the distributed autonomous organizations
(a.k.a. DAO), the largest crowd-funding blockchain project
with assets of about 60 million USD [27]. Due to a viciously
modified recursive call in its smart contract, the DAO was
attacked and resulted in a huge loss in 2016.
This accident has led to an intense discussion over the
security of smart contracts. Considering that the research on
the blockchain-based IoT is in full swing in recent years, it
is important to explore the hidden danger as soon as possi-
ble. Therefore, we search for published literature on Google
Scholar (with keywords such as smart contract, security and
IoT) to discover the security issues in recent research works,
and summarize the related surveys between 2016 to 2020 in
Table I. As observed from the table, Luu et al. [26] firstly
discovered four kinds of security bugs in Ethereum contracts
and built an analyzing tool to detect bugs. After that, security
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
2 IEEE INTERNET OF THINGS JOURNAL

TABLE I: A summary of existing surveys related to smart contract security.

Pub.
Literature Scope Advantages Limitations
year
Firstly document security vulnerabili-
No security issues in smart
Luu et al. [26] 2016 List 4 security vulnerabilities ties in Ethereum smart contracts and
contract-based IoT
propose recommendations for them
Firstly identify the pros and cons of Only the immutability of
Christidis and Devet- Discuss some opportunities and chal-
2016 blockchain and smart contract based smart contracts is men-
sikiotis [28] lenges of smart contracts in IoT
IoT tioned
Investigate 12 security vulnerabilities Provide the first systematic exposition No security issues in smart
Atzei et al. [29] 2017
and 5 attacks of security vulnerabilities in Ethereum contract-based IoT
Provide a modified taxonomy of secu-
List 22 security vulnerabilities and test No security issues in smart
Dika [30] 2017 rity vulnerabilities and test the avail-
9 security tools against vulnerabilities contract-based IoT
able security tools
Firstly conduct a systematic mapping
Discuss 6 security issues and propose No security issues in smart
Alharby et al. [31] 2018 study as the methodology to produce a
the corresponding solutions contract-based IoT
map of current smart contract research
Firstly discuss the possibilities and Only discuss the privacy is-
Investigate 3 challenges of smart con-
Hanada et al. [19] 2018 limitations of smart contracts for sue and impact of bugs in
tracts in IoT
machine-to-machine communication smart contract-based IoT
Discuss security considerations in Only discuss observability
Fotiou and Discuss opportunities and challenges
2018 smart contract-based IoT and present and immutability of smart
Polyzos [32] of smart contracts in IoT
new design choices contracts
Present the most comprehensive threat
Describe 16 security attacks against No security issues in smart
Ferrag [33] 2019 models that are considered by the
blockchain-based IoT contract-based IoT
blockchain in IoT
Investigate 6 security tools and discuss Propose a four-layer blockchain archi- Only discuss a little on se-
Wu et al. [15] 2019 the problems of blockchain-based IoT tecture, compare numerous works and curity issues in blockchain-
from three aspects analyze their pros and cons based IoT
Propose a taxonomy of security veri- Discuss the security solutions from No security issues in smart
Liu et al. [34] 2019
fication and discuss the pros and cons three new aspects contract-based IoT
List 8 security methods against vulner-
Rouhani and Recognize a problem in smart contract No security issues in smart
2019 abilities, review the performance and
Deters [35] and provide a novel solution contract-based IoT
IoT Integration of smart contracts
Di Angelo and Investigate 27 security tools against Provide the most comprehensive com- No security issues in smart
2019
Salzer [36] vulnerabilities parison of 27 security tools contract-based IoT
Provide the most comprehensive re- No security issues in smart
Demir et al. [37] 2019 Investigate 28 security issues
view of 28 security issues contract-based IoT
Analyze 16 security risks in Hyper- Firstly analyze potential security risks No security issues in smart
Yamashita et al. [38] 2019
ledger Fabric smart contracts in Hyperledger Fabric smart contracts contract-based IoT
Use Technology-Organization- Only roughly mention 4
Identify 13 key-determinants for smart
Schmitt et al. [39] 2019 Environment framework and four risks in smart contract-
contract-based IoT
interviews to identify pros and cons based IoT
List 12 security vulnerabilities, issues Conduct the first systematic exami-
No security issues in smart
Li et al. [27] 2020 of criminal and under-optimized smart nation on security risks to popular
contract-based IoT
contracts, with 6 attacks blockchain systems
Define 7 attacks and list 10 security Examine smart contract-based attacks No security issues in smart
Sayeed et al. [40] 2020
tools and the results of their exploitation contract-based IoT
Compare typical smart contract plat-
Discuss opportunities of smart con- No security issues in smart
Zheng et al. [41] 2020 forms and give a categorization of
tracts for industrial IoT contract-based IoT
smart contract applications
López Vivar et Analyze 12 security vulnerabilities, 2 Conduct the most comprehensive ex- No security issues in smart
2020
al. [42] attacks and 18 security tools periment of 18 security tools contract-based IoT
Firstly discuss 3 aspects of security
Discuss 3 aspects of security issues of
issues, corresponding solutions, re-
Our work 2021 smart contracts in IoT and correspond-
search challenges and future directions
ing solutions
for smart contracts used in IoT

2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
K. PENG et al.. SECURITY CHALLENGES AND OPPORTUNITIES FOR SMART CONTRACTS IN INTERNET OF THINGS: A SURVEY 3

Check external
Oracles
data source
Preset trigger conditions
Specific time/event/... Smart contract Condition 1: response 1
Condition 2: response 2
Preset response rules ...
Specific transaction/operation/... State Value Condition N: response N

Block 0 Block 1 Block 2 ...

Fig. 1: The operating mechanism of smart contracts.

issues of Ethereum platform and its programming language II. OVERVIEW OF S MART C ONTRACTS FOR I OT
were systematically reviewed in [29]. Yamashita et al. [38] A. Basics of Blockchain and Smart Contract
firstly analyzed security risks in Hyperledger smart contracts.
A blockchain is a distributed database with all transaction
Authors in [27], [30], [36], [37] gave more comprehensive
records continuously appended and unmodified in a grow-
summaries of vulnerabilities, attacks and corresponding solu-
ing list of data blocks [43]. The implementation of the
tions in smart contracts. However, the surveys above lack the
blockchain integrates a variety of techniques including dis-
research cases in an IoT setting. Considering the deployment
tributed consensus, encryption algorithms, peer-to-peer com-
of blockchains and smart contracts in IoT, there are only
munication, timestamp servers, smart contracts, etc. The core
surveys discussing general opportunities and challenges of
of a blockchain is consensus, which is used to achieve avail-
smart contracts [19], [28], [32], [39], [41], or surveys on
ability and consistency in a distributed system. Representative
only blockchain security [15], [33], [35], while none of them
consensus mechanisms [44] include PoW (Proof of Work),
explores the smart contract security issues and solutions for
PoS (Proof of Stake), PBFT (Practical Byzantine Fault Toler-
IoT thoroughly.
ance), DPoS (Delegated Proof of Stake), etc. The emergence
For the purpose of filling the gap in this field, we intend to
of the blockchain allows participants to exchange unforgeable,
explore the vulnerabilities and attacks in smart contracts which
non-tamperable and traceable data without reliance on any
may seriously affect the stability of the IoT ecosystem, and re-
trusted third party.
mind developers of avoiding blunders, alleviating unnecessary
losses more effectively and integrating blockchain technology A smart contract is a decentralized program with a set
into the development of IoT more firmly. Specifically, our of self-enforcing agreements on the blockchain [26]. As a
major contributions are summarized as follows. representative technology in the second generation of the
blockchain, smart contracts offer more extensive and practical
• We review the security issues and solutions in the integra-
applications beyond the early blockchains only designed for
tion between smart contracts and the IoT systematically
cryptocurrencies. A typical operating mechanism of a smart
and comprehensively for the first time.
contract is as shown in Fig. 1. Generally, after being signed by
• We explore the smart contracts in all mainstream
relevant parties, the smart contract is loaded to the blockchain
blockchain platforms for IoT usage, and present our
in the form of program code. Then it is propagated by peer-to-
findings of the underlying security issues from three
peer network, verified by blockchain nodes, and stored into a
important aspects: inherently vulnerable particularities,
newly-generated block. The smart contract encapsulates preset
programming vulnerabilities, and feasible attacks.
states, values, trigger conditions for auto-execution (e.g., when
• We summarize and compare recent advances of the
a specific time or event comes) and specific response rules for
corresponding solutions in a compact form toward the
new transactions or other operations. The blockchain plays the
aforementioned three aspects of security issues.
parts of monitoring the state of smart contracts and checking
• We outline some remaining challenges and future re-
external data in real time, waiting for the trigger to activate
search directions in this new and largely open area.
contracts.
The remainder of this survey is organized as follows. In
Section II, we provide an overview of smart contracts, with
a focus on how they work and how they are deployed to the B. Framework of Smart Contract
IoT. Section III presents a threat model of smart contracts for The basic framework of a smart contract mainly contains
the IoT and summarizes the current security issues. Following five layers: data layer, transport layer, contract layer, execution
from the above that, we present the major solutions to cope layer and application layer, as shown in Fig. 2.
with these security issues in Section IV. Section V presents Data Layer: The data layer includes on-chain and off-
the challenges and future research directions, and finally, chain data, which are necessary data sources of running a
Section VI concludes the survey. smart contract. For observability and verifiability, state data

2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
4 IEEE INTERNET OF THINGS JOURNAL

mance and compatibility, most smart contract platforms adopt

Application
IoT Finance
layer
Blockchain App. / API
Contract Parameter and Standard
layer Business logic code
Execution
Docker EVM
layer
Transport Communication
layer protocol
Data block / API
On-chain data Off-chain data
Data layer
State Transaction Contract code
Fig. 2: The basic framework of smart contracts.
and transaction data are generally stored on the blockchain.
The original contract code is stored either on the chain or
off the chain. At present, most blockchain systems choose
to publish the code and application data to the blockchain,
then execute them on the chain. However, since everything
on the chain is transparent to everyone, security and privacy
issues need attention. Another way is to store the hash of
a smart contract on the blockchain, and to save the original
contract through a file system or reliable data platform using
hash index. This relieves the pressure of observability and
scalability of the blockchain.
Transport Layer: The transport layer encapsulates the
communication protocols and communication mechanisms
for supporting on-chain-to-on-chain and on-chain-to-off-chain
data transmission. For data from outside the chain, we have to
be careful where they come from and how they communicate
with other data to ensure the credibility.
Contract Layer: The contract layer contains parameters
for specific functions (e.g., contract management, user admin-
istration and data management) and business logic as rules of
execution, and the code of program logic and legal content
written in standard programming languages. In this layer, how
to design the underlying logic, programming languages and
functions are extremely important for blockchain developers,
because a majority of vulnerabilities and attacks could arise
here.
Execution Layer: The execution layer refers to the runtime
environment for smart contracts, including virtual machines
and the Docker [45] which provide sandboxes for executing
contract code, isolating and restricting the resources of the
contract. To reduce the resource cost and improve perfor-
lightweight virtual machines such as the Ethereum Virtual
Machine (EVM). The design of a virtual machine is also
Energy …
critical for the secure execution of each smart contract. More
seriously, once being executed on chain, the immutability of
smart contracts means it is hard to reverse and repair the
Code existing security problems.
Legal Application Layer: The application layer is deployed on
content the basis of the former layers. In this layer, decentralized
applications are produced to serve for smart contracts to
communicate with other computers and practical applications
Other virtual
(e.g., the IoT systems, financial services and smart energy
machines
ecosystems). A secure API (Application Program Interface)
will facilitate the interaction between abundant applications
and smart contracts on the blockchain.
Communication
mechanism
C. Implementation of Smart Contract
The concrete implementation of a smart contract differs
in diverse blockchain platforms. Among all these platforms,
Ethereum is the pioneer to implement the idea of smart con-
Other data tract in practical and then becomes the most widely used smart
contract platform for now. With an EVM and a built-in Turing-
complete programming language, Solidity, Ethereum enables
developers to create consensus-based, extensible, standardized
and decentralized applications on its blockchain [23]. The
syntax of Solidity (c.f. Fig. 4) is similar to JavaScript, and the
source code is eventually compiled into bytecode and runs in
the EVM. Also, Ethereum provides abundant interfaces (e.g.,
JSON-RPC, JavaScript and Geth) for external program calls.
The core elements of an Ethereum smart contract include
message calls, transactions, gas, logs, instruction sets, code
libraries, storage, and accounts as the basic unit of it. Ac-
counts maintain a series of state objects which store state
information in Ethereum. There are two types of accounts:
externally owned accounts (EOAs), which store the balance of
the account and are controlled by private keys; and contract
accounts (CAs) which store the balance and contents of the
contract, and are controlled by contract code and only activated
by EOAs. Accounts enable the creation and verification of
transactions on Ethereum blockchain.
Seeing the success of Ethereum, dozens of other smart
contract platforms popped up in the last few years, such
as Hyperledger Fabric [45], Enterprise Operation System
(EOS) [46], TRON [47] and IOTA [48]. A brief comparison
of these platforms is illustrated in Table II.
Different from Ethereum, the goal of Hyperledger Fabric
is to realize a universal basic framework of permissioned
blockchain with the PBFT consensus, meaning that a network
can be operated under a governance model that builds the trust
between participants, though participants may not trust each
other. The Fabric smart contract, also known as chaincode, is
a program written in Go (also supports other programming
languages such as Node.js and Java), and it implements
predefined interfaces and runs in a Docker container isolated
from the endorsing peer process.
EOS is developed as an innovative solution to Ethereum’s
lack of scalability with a more efficient consensus protocol,

2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
K. PENG et al.. SECURITY CHALLENGES AND OPPORTUNITIES FOR SMART CONTRACTS IN INTERNET OF THINGS: A SURVEY
TABLE II: The comparison of representative smart contract platforms.
Ethereum
Mainnet launch date July 2015
Consensus mechanism PoW
Permission Permissionless
Transactions per second 15-25
Contract language Solidity
Contract execution envi-
EVM
ronment
Transaction fee Depend on gas price
DPoS. The EOS smart contracts are written in C/C++, which
promotes programming flexibility. Running an EOS smart
contract does not need transaction fees. Additionally, EOS
utilizes the pre-compiled WebAssembly to implement its smart
contracts onto the blockchain, which boosts the efficiency of
contract execution when compared to other Ethereum-based
smart contracts.
Similar to EOS, TRON also adopts a customized DPoS
consensus protocol for better scalability and higher throughput.
The TRON platform is developed on Ethereum and its smart
contracts are written in the Solidity language. The virtual
machine of TRON is TVM (TRON Virtual Machine), which
connects seamlessly with the existing Solidity smart contract
development ecosystem. TVM employs the concept of Energy
to dispose of fees.
IOTA is a revolutionary distributed ledger technology espe-
cially designed for the IoT. It is based on the tangle, a new type
of Directed Acyclic Graph (DAG). The tangle can overcome
the inefficiency of the existing blockchain technology, theoret-
ically process an infinite amount of transactions and create a
new method for the consensus of a decentralized system. There
is no transaction fee through IOTA, too. IOTA smart contract is
an ongoing work of the IOTA Foundation. Each smart contract
can be executed in the local environment without forcing the
entire network to execute them.
D. Smart Contract Applications for the IoT
Smart contracts endow IoT with significant benefits:
• Data in smart contracts cannot be deleted or modified.
Any behavior will be permanently recorded and witnessed
by each participant. Thus the transparency and traceabil-
ity of the whole operation and transaction history can
be ensured, and the interference of malicious behaviors
in normal executions of IoT systems will be greatly
alleviated.
• The inherent decentralization avoids the influence of
centralization factors and improves the cost-effectiveness
of smart contract-based IoT applications.
• When conditions are met, the contract code will be
automatically executed, which avoids the manual process
and ensures that the contract issuer cannot breach the
contract.
With these advantages, smart contracts have been adopted
in many typical scenarios of the IoT, as illustrated in Fig. 3,
and are able to perform different parts in interacting with the
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
Things Journal
5
Hyperledger Fabric EOS TRON IOTA
October 2018 June 2018 June 2018 July 2016
PBFT DPoS DPoS Tangle
Permissioned Permissionless Permissionless Permissionless
3500 4000 2000 10000
Go C/C++ Solidity Abra
Docker WebAssembly TVM Abra VM
No No No No
IoT devices and participants. Here, we briefly introduce how
smart contracts are leveraged to complete common IoT tasks.
Asset and Transaction Management: In scenarios like
energy trading and sharing asset rental, smart contracts can
accomplish tasks such as supervising the transaction process
and authorizing physical assets to users [12], [19], [49], [50].
Any transaction can be completed automatically and recorded
permanently on the blockchain as long as developers make
rules and trigger conditions for contracts. For instance, a
German company named Slock.it [51] utilizes smart con-
tracts for sharing, renting and selling physical assets without
intermediaries. In this way, Blockchain and smart contract
technology can ensure mutual trust between users through
its decentralization, so that users can realize a true sharing
economy and protect user privacy.
Routing and Workload Balancing: Smart contracts can
also fulfill the management of new workloads when they are
submitted to the IoT network [52], [53]. Firstly, smart contracts
need to analyze which tasks are the actual tasks that the IoT
device is in charge of. Then a workload balancing algorithm
is deployed with consideration of the device workload and,
hence, the allocation of the total workload can be inclined to
the unloaded devices from the devices with heavy tasks.
Distributed Computing: Smart contracts can be devel-
oped to enable the acquisition and provisioning of computing
resources [20], [54]–[56]. Distributed computing with smart
contracts is a new solution to achieve an intelligent match
of idle nodes as computing resource providers and customers
(computing resource demanders). This solution fully develops
and leverages the existing computing resources, simplifies the
process of computing services, which leads to lower comput-
ing costs and increased quality-of-service in IoT scenarios.
Data Traceability and Auditability: The supply chain is
an essential application of IoT. The most critical properties
for the supply chain are data traceability and auditability,
which are also the most significant advantages of blockchain.
Inspired by this common ground, a great deal of work was
conducted for blockchain and smart contract-based supply
chain applications and related agriculture applications [57]–
[63]. Bocek et al. [64] introduced an application that tracks
the distribution of medical products via IoT sensors and smart
contracts. To ensure the quality and environmental conditions
compliance of the products upon the delivery, sensors in each
parcel collect and transfer the relevant data to the blockchain.
A smart contract of the application receives data, stores results
on the blockchain and reports back to the receiver as well as to
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
6 IEEE INTERNET OF THINGS JOURNAL

Sharing
economy

Asset and Device

Smart
E-health transaction operation
home
management management

Smart
Routing and contracts Access
workload for the IoT control IoT security
balancing
Smart grid and privacy

Data
Distributed traceability
computing and
auditability
Distributed
Supply chain
computing
platform Agriculture

Fig. 3: The applications of smart contracts for the IoT.

the distributor. This technology guarantees the data integrity,
credibility and publicly accessibility when people want to trust
the data provided by IoT devices.
Access Control: Smart contracts are useful for expressing
fine-grained context-aware access control policies and au-
thenticating IoT users [17], [65]–[69]. For example, a smart
contract with methods that obtain, manage and distribute the
public keys of users with different permissions. Zhang et
al. [18] presented a smart contract-based framework to imple-
ment the access control lists and achieve a distributed access
control for IoT systems, where three types of smart contracts
are defined: multiple access control contracts for each pair of
subject and object, a judge contract with misbehavior-judging
functions of the subjects for the access control, and a register
contract for configuration of the former smart contracts. Their
framework has been tested to be feasible and secure with real-
world experiments. Considering the limited computing power
of IoT devices, the use of a decentralized blockchain-based
access control system can improve the flexibility and security
of the system. This type of system also helps deal with illegal
operations by smart contracts. This application is reasonable
and promising.
Device Operation Management: Smart contracts also pro-
vide systems that monitor and manage multifarious operations
of IoT devices, such as CRUD (Create, Read, Update, Delete)
and encryption operations [70]. In [71], smart contracts are
simply used to store data from smart meters and smartphones.
Smart devices check values on Ethereum time to time so as
to change their states. Hash values and updating rules of the
firmware on devices can also be stored in a smart contract,
so that devices can query the smart contract for the latest
version and the hash of the firmware from IPFS, a peer-to-
peer distributed file system, and then update themselves [28].
III. S ECURITY I SSUES
Although the blockchain technology provides new features
and opportunities for traditional IoT applications through
smart contracts, issues that impede smart contracts for fully
satisfying the requirements of service providers and users
have shown up, such as relatively low performance and high
overhead from computation-intensive consensus and smart
contract operations [19]. Nevertheless, these burdens are worth
their weight given the aforementioned significant benefits on
offer.
Among these issues, security issues are the most critical
and primary things to be considered to achieve safer and
better usage of blockchain and smart contract technology in
the IoT environment. To this end, we conduct a thorough
investigation of the security characteristics in current smart
contract techniques and propose a threat model to describe
the security issues of smart contract-based IoT applications in
this section.
A. Threat Model
When attempting to investigate potential security issues and
reduce security risks to an IoT system, it is valuable to build
a threat model for analyzing and classifying known attacks. In
this part, we adopt the famous STRIDE framework to elaborate
our threat model.
STRIDE [89] is a set of threat modeling methodology
developed by Microsoft. According to the core underpinning
of information security (confidentiality, integrity and availabil-
ity) and its basic properties (authenticity, non-repudiability
and authorization), STRIDE divides threats into six dimen-
sions: spoofing, tampering, repudiation, information disclo-
sure, denial of service (DoS), and elevation of privilege. In

2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
K. PENG et al.. SECURITY CHALLENGES AND OPPORTUNITIES FOR SMART CONTRACTS IN INTERNET OF THINGS: A SURVEY 7

TABLE III: The threat model of security issues and solutions of smart contracts for the IoT.
Different Types of Security Issues Issue Sources Threats Corresponding Solutions
Standardize the programming [72] and use
Observability [32] Data layer I
cryptographic technologies to protect privacy
Adopt standards from contract law to alter
Immutability [73] Execution layer D
or repeal smart contracts [73]
Use a trusted third party which provides
Inherently Vulnerable Lack of trustworthy data
Data layer ST authenticated data [75] or use multiple dis-
Particularities feeds [74]
tributed oracle servers [76]
Use third-party services such as Ora-
Randomness generation [77] Data layer T
clize [78] to obtain safe random numbers
Use block.number [26] and an average block
Timestamp dependence [29] Data layer T
time to estimate time
Guard condition [26]; launch a specific con-
Transaction-ordering depen-
Data layer T text for the output as a prerequisite for
dence [26]
transactions; use logical clocks
Add a cache layer [79] to ensure that the
Read after write [38] Data layer T conflicting transactions must be waiting until
the previous transactions are committed
Unchecked call/send [29] Contract layer STE
Out-of-gas send [29] Contract layer D
Type casts [27] Contract layer D
Security auditing methods:
Integer over/under flows [74] Execution layer T
Programming a) Signature matching
Authorization through
Vulnerabilities Contract layer SE b) Formal verification
tx.origin [74]
c) Symbolic execution
Missing constructor [80] Contract layer T
Storage allocation exploits Contract layer D
Non-determinism [38] Contract layer TD
Fake EOS [81] Contract layer T
Adopt “Checks / Effects / Interactions” pat-
Reentrancy attack [82] Contract layer ST
tern [83] or a mutex [84]
S T D
Attacks against Eclipse attack [85] Transport layer Upgrade user clients to 1.8.1 [86]
E
Smart Contracts
Use a timelock; avoid the operations that can
DoS attack [84] Contract layer D be manipulated to reach the gas limit; adjust
the operation cost dynamically [87]
See solutions to Transaction-ordering depen-
Dynamic library attack [29] Data layer T
dence
Add a specific available period for the per-
RAMsomware attack [88] Contract layer TD
mission to terminate the attack anytime [88]

the following, we introduce STRIDE in the context of the
smart contract-based IoT.
Spoofing: Spoofing refers to the ability to impersonate an-
other entity (e.g., another person or computer) on the system,
which violates the security property of authenticity. When IoT
nodes interact with each other through smart contracts, mali-
cious attackers may exploit the authentication vulnerabilities
in smart contracts and masquerade as developers to gain the
access illegally.
Tampering: Tampering refers to malicious modification of
data, which violates the integrity. Since the development of the
smart contract technology is immature, vulnerabilities appear
at different stages and can hardly be fixed by developers. With
the knowledge of these vulnerabilities, attackers can exploit
them and tamper with the contents of smart contracts, then
modify the corresponding IoT information.
Repudiation: Repudiation is the ability of an attacker to
make it impossible to link an action one performed to himself,
which violates the security property of non-repudiability.
Information Disclosure: Information disclosure threats in-
volve the exposure of information to unauthorized individuals,
which violate the confidentiality. Due to the open-source
nature ofthe smart contract technology, the transactions and
contents of smart contracts are public to all users, thus the data
stored on the IoT systems is susceptible to privacy violation
by malicious attackers.
DoS: DoS attacks deny service to valid users, which violate
the availability. The requirement of availability is to ensure
that the IoT information can indeed be used by authorized
users. In other words, legitimate users can use the required
information when needed, and will not lose data resources due
to unexpected errors. Adversaries may deliberately invalidate
IoT data or services to deny users access to IoT systems by
many attack techniques, such as launching a DoS attack at

2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
8 IEEE INTERNET OF THINGS JOURNAL
smart contract-level.
Elevation of Privilege: In this type of threat, an attacker
gains privileged access without permission and thereby can
effectively penetrate the blockchain system or even become
part of the trusted system itself. This threat violates the
security property of authorization.
Based on the STRIDE model, we can analyze the framework
and operating mechanism (mentioned in Section II) of smart
contracts in the IoT system, and identify the security issues
that have been discovered, then investigate the mitigation
measures to build our threat model (c.f. Table III).
B. Classification of Security Issues
This subsection introduces the important security issues of
smart contract-based IoT applications. As is demonstrated in
Table III, we classify them into the following three categories
according to the characteristics of smart contracts and utilize
the STRIDE framework to assess the impacts of different
issues.
1) Inherently Vulnerable Particularities: Some inherent
particularities brought by the design of blockchain prototype
and different smart contract platforms may have security risks
for smart contracts and they are vulnerable to be attacked by
malicious users in IoT scenarios. We will go through each of
them in the following.
Observability: Most blockchain platforms are open-source,
such as Ethereum and EOS. All bytecode of smart contracts
can be observed by IoT users on the blockchain, and a small
part of contracts’ source code is also open to the public. Thus,
all vulnerabilities are visible to the public, too. Apparently, this
observability violates the confidentiality of IoT security. If the
developer is negligent or inexperienced, and the code of smart
contract is flawed, it is very easy to be exploited and attacked
by hackers [32]. Furthermore, the more powerful the smart
contract is, the more likely it is to have vulnerabilities, and
the more likely it is to be noticed by more people. Once the
key vulnerabilities are discovered, it will cause losses to the
entire IoT system users and managers [90].
Immutability: At the beginning of the design for improving
the credibility, the smart contract (e.g., the Ethereum) was
devised with a pattern that cannot be modified once deployed
on the blockchain system [73]. However, the immutability
of the smart contract is a double-edged sword, because if
it is written by humans, there could always be errors and
defects. The design of Ethereum violates the general rule of
programming, and thus it may take such impact of the contract
vulnerabilities more widespread, durable, and even irreparable.
Lack of Trustworthy Data Feeds: To manage the massive
data from IoT devices, smart contracts have to request data
feeds from outside the blockchain, especially in the supply
chain [64]. Whereas, smart contracts are designed to utilize the
information only inside blockchain so as not to overwhelm the
lightweight nature. The only way to make contact with the out-
side world is via the oracle [38], a means of data feeds usually
given by a third party. The problem is whether the external
data is trustworthy or not [74], [91]. If a malicious oracle
imports corrupt data onto the chain, it will cause irreparable
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
damages to the IoT system and threaten the IoT integrity.
Besides, oracles must minimize the blockchain response time
to provide time-variant IoT data and also to prevent itself from
sharply fluctuating due to malicious nodes [76].
Randomness Generation: When an IoT system runs for
the first time, it needs to generate random numbers as device
identities. To generate random numbers in Ethereum-like smart
contracts, developers need to use a pseudo random number
generator (PRNG). The alarming thing is the case that the most
commonly-used PRNGs introduced below are vulnerable [77],
which may damage the authentication of IoT devices.
• PRNGs based on the block variables. For instance,
block.difficulty, block.number and block.timestamp. All
of the above block variables could be manipulated by
blockchain miners because these block variables are
shared on the same block.
• PRNGs based on the hash of old blocks. Each block
on Ethereum blockchain has a certified hash value that
can be obtained by the block.blockhash function. This
function is often used incorrectly.
Timestamp Dependence: Some smart contracts use the
block timestamp as a trigger for certain operations to achieve a
variety of applications, such as locking money for a period of
time. Usually, the timestamp is derived from the miner’s local
time, but the time fluctuates in a range of about 900 seconds
[29]. When other nodes accept a new block, they only need to
verify whether the timestamp is later than that of the previous
block and the error between it and the local time is within
900 seconds. A miner can profit from the conditions that are
favorable to him by slightly adjusting the timestamp of the
block. If the block timestamp is incorrectly used in a smart
contract and maliciously tampered with, it will be a severe
threat for the integrity of IoT systems.
Transaction-Ordering Dependence: In Ethereum
blockchain, the execution order of transactions depends
on the miners. However, it takes a certain amount of time
for a transaction to be spread out and acknowledged by all
miners in a block. If the state of a transaction which is being
executed is different from the assumed state, the transaction
order decided by miners may affect the execution of given
transactions [26]. This phenomenon occurs when more
than one transaction concurrently invokes the same contract
that miners could tamper the order in which transactions
are executed. In Hyperledger Fabric, the same issue also
exists [79]. If the state where a transaction will be run is not
for sure, the property safety of ordinary IoT users may be
violated.
Read after Write: In distributed systems, Read-Your-Write
consistency is a guarantee that once a record has been updated
to a new value, any request to read the record will return
to the updated value. In Hyperledger Fabric blockchain, this
consistency is not supported. Hence, when reading a record
that has already been written during the same transaction,
the blockchain will return the old value of the record [38].
This read-write conflict may lead to an undesired phenomenon
that some of the transactions may become invalid when
transactions are submitted concurrently in the system.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
K. PENG et al.. SECURITY CHALLENGES AND OPPORTUNITIES FOR SMART CONTRACTS IN INTERNET OF THINGS: A SURVEY
2) Programming Vulnerabilities: Another common security
problem comes from the programming process of smart con-
tracts, especially for a new language like Solidity. Developers
are prone to mistakes when coding the contract. Ethereum
has repeatedly experienced many security accidents caused by
contract vulnerabilities since it came online. A report [92]
points out that in Ethereum, 89 percent of smart contracts
have more or less code vulnerabilities. Apart from that, other
platforms like EOS and Hyperledger Fabric are also faced with
the programming vulnerabilities to some extent.
Next, we enumerate the most common vulnerabilities in the
process of programming smart contracts in IoT applications.
These vulnerabilities are highly probable to be exploited to
launch attacks against smart contracts and IoT systems by
hackers.
Unchecked Call/Send: There are many functions (e.g., call,
send and delegatecall) to perform external calls in Solidity.
The functions call and send return a Boolean value to indicate
whether the invocation succeeds or not, just like a simple
warning. If the external call (initiated by call or send) fails, the
transaction executing these functions will not be rolled back.
Instead, the functions will simply return a false. However,
when the return value is not checked yet, an error will
occur but the rollback will not occur. This allows a called
smart contract to run code with the privileges of the calling
smart contract and gives the attacker unauthorized access
to protected functionality within the smart contract. Here is
an example of this vulnerability in Fig. 4. In this case, a
call is used to invoke an external function < address >
.call(bytes4(keccak(“somef unc(params)00 ), params)), but
it will only return a false to the calling one [29]. In Hyper-
ledger Fabric, a similar risk also exists [38].
Out-of-gas Send: In order to prevent the infinite loop of
contract code, Ethereum added the concept of code executing
consumption. After the contract code is deployed to the
Ethereum platform, when the EVM executes the code, each
step in the code consumes a certain amount of gas. Gas could
be regarded as “energy”, and the external caller provides a
certain amount of gas when calling a function of the contract.
If the gas amount is larger than the “energy” required by this
part of the code, it will be executed successfully, otherwise an
out-of-gas exception will happen, and the contract state will
be rolled back [29]. Forcing a smart contract into a state where
it needs more gas than the limit to run can make it incapable
of running.
Type Casts: When types in Solidity are used for direct
calls [27], the caller must declare the callee’s interface and
cast it to the callee’s address when calling. However, when
the compiler checks the calling statement, it does not look
for type mismatch errors or throw an exception. Hence, it has
become a hidden danger that programmers have not always
aware of.
Integer Over/Under Flows: EVM specifies a fixed-size
data type for integers, which indicates that an integer variable
can only represent a certain range of numbers. For example,
a variable uint8 can only store integers in the range from
0 to 255. Without notice, variables in Solidity can be ex-
ploited to launch attacks [74] as long as the user’s input is
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
9
pragma solidity ^0.4.10;
contract MyCall
{
event CallResult(bool);
function extCall(address _sc)
{
bool result = _sc.call(bytes4(keccak256(“func1()”)));
CallResult(result);
}
}
contract SC
{
// call() is for the external calls
function func1()
{
revert();
}
}
Fig. 4: A smart contract with unchecked call/send vulnerability
in Solidity.
not checked and the calculations are executed, causing the
numbers to exceed the range of data types. The forms of
integer over/under flows include multiplication, addition, and
subtraction over/under flows. The good news is, OpenZeppelin
provides a Solidity library called SafeMath that can effectively
avoid this vulnerability.
Authorization through tx.origin: All Ethereum smart con-
tracts have an address object and can also call for code
from other addresses. Different contract addresses represent
different contracts and the permissions they have. In Solidity,
there is a global variable named tx.origin that traverses the call
stack completely and then returns the address of the account
that submitted the invocation or transaction originally. It is not
recommended to use this variable to authorize IoT users [74]
because it will incur the hazard of attacks similar to phishing
attacks which induce users to check identities and authenticate
via vulnerable contracts.
Missing Constructor: Similar to object-oriented program-
ming languages, developers can initialize contract objects
through constructors in smart contracts. When creating a
contract, the constructor is called to initialize data of the
state variable. The vulnerability of missing constructor is that
the constructor name is different from the contract name,
but it is a public type, so it will become a public function
that can be called by anyone [80]. Generally, constructors
are used to define the administrator’s address, the amount of
tokens and so on when initializing the contract. Therefore,
we can imagine the hazard of their becoming public. Many
components of the entire infrastructure for the IoT system, for
instance, access control and the management of tokens, will
be basically broken.
Storage Allocation Exploits: Each variable is assigned to a
storage location when being stored. In Solidity, there are two
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
10
different variables for storage, storage and memory. Storage
variables are permanently stored on the blockchain, while the
memory variables are temporary and will be removed after the
external call ends. However, Solidity currently stores complex
data types as local variables in functions, such as array and
struct, in storage by default. In addition, for state variables, the
storage order is generally arranged in the order of appearance.
Solidity has a distinct difference from traditional languages
in that it allows developers to define a reference to storage.
The uninitialized external pointer (reference) will point to the
starting address by default. If it is not initialized and the
assignment is done directly, the state variable at the 0 address
will be overwritten and errors may occur.
Non-determinism: Determination of the contract business
logic in Hyperledger Fabric is violated by the instructions
related to random numbers from Go language, such as the
global variable, random number generation, system timestamp,
map structure iteration, reified object addresses, field declara-
tions, and concurrency of program [38]. This non-determinism
in smart contracts will lead to inconsistent results after the
contract execution and may violate the availability of IoT
applications.
Fake EOS: Malicious users can conduct fake transactions
by issuing an EOS-based fake token and naming it “EOS”,
and then transferring fake EOS tokens to the account of a
target contract. If the contract developer forgets to detect the
token issuer, the fake token will be mistakenly regarded as the
real EOS token [81]. Apart from that, if attackers force the
transfer function of the target contract to be invoked, and the
target contract does not detect the source of transfer, attackers
can write the fake transfer notification into transfer function
to fool the developers.
3) Attacks against Smart Contracts: Here we mainly review
the existing attacks against smart contracts in the IoT environ-
ment. These attacks more or less take advantage of the above-
mentioned particularities and vulnerabilities of blockchain
network and smart contracts. Once the attack is launched, it
will cause huge losses to the IoT system and participants.
Reentrancy Attack: In Ethereum, when a contract invokes
another contract, the current execution process will suspend
until the call finishes, which results in an intermediate state
that can be exploited. The hacker utilizes the intermediate state
to submit another call when the contract has not finished the
external call, thus the reentrancy attack happens [82]. The
DAO attack mentioned above is manipulated by this attack.
With this threat, hackers can track the transaction and then
steal or falsify the critical information of users or products in
IoT applications [93].
Eclipse Attack: The eclipse attack [85] is a network attack
implemented by other nodes. The attack technique is to hoard
and occupy the peer-to-peer connection slots of a node, keep-
ing it in an isolated network. More specifically, the attack aims
to block the latest blockchain information from the eclipse
node, thereby isolating the node from other normal nodes in
the network. In this way, the victim node becomes unable
to see the blockchain information, hence it is delayed to see
various parameters that may be used in internal computations
of the smart contract, resulting in an incorrect output of the
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL
contract that the attacker could take advantage of [86]. For
instance, it can replace a normal user’s IP address with the
adversary’s IP address to track the user’s private information
in an IoT system [93].
DoS Attack: For resource-constrained IoT devices with low
power and storage capacity, the DoS attack is one of the most
severe and common threats to the IoT ecosystem. There are at
least two approaches to launch the DoS attack against smart
contracts [84], the purpose of which is to make the contracts
not work for some time or permanently and then interfere with
the IoT devices.
• Launching DoS through (unexpected) revert: In
Ethereum, if the change of state of the smart contracts
depends on the result of the execution of the external
function and developers do not protect the situation that
the execution fails continuously, the smart contracts may
be under the DoS attack.
• Launching DoS through the gas limit: As mentioned
above, Ethereum stipulates the gas limit that each block
can spend, and if it exceeds the limit, the normal op-
erations will fail. Some operations (e.g., transferring an
asset to all users at one time) are very likely to reach the
upper bound of the block gas limit. Thus, if the cost of
gas is controlled, the attacker will achieve his malicious
purpose.
Dynamic Library Attack: Consider a case when invoking
a contract that can update several parts of its components
dynamically [29]. Although no one can modify the contract
code once it is issued on the blockchain, it is possible for a
malicious contract owner to write a smart contract with up-
datable components. If so, the owner can attach a controllable
component which may impair the IoT system to this specific
smart contract. This attack exploits the transaction-ordering
dependence vulnerability mentioned above.
RAMsomware Attack: This attack is a classic time-of-
check to time-of-use (TOCTOU) attack which leverages the
EOS feature that developers can update their smart contracts
without notifying their users [88]. Assuming that an attacker
has the eosio.code permission of users and creates a malicious
smart contract that invokes itself recursively while storing
useless information to drain the victims’ EOS-RAM. In this
way, the EOS-RAM will be locked until the attacker stops the
occupation and the related IoT applications will be severely
affected. In the meanwhile, the attacker can ask for a ransom
in exchange for releasing the RAM resource.
IV. S OLUTIONS TO THE S ECURITY I SSUES
The issues shown above have seriously harmed the interests
of many owners. Especially in complex IoT environments,
we need to fully understand these universal problems before
applying smart contracts and take corresponding preventive
measures. Fortunately, more and more researchers have begun
to study the solutions towards these issues in recent years.
Here we summarize these feasible solutions in response to the
security issues for each part (c.f. Table III).
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
K. PENG et al.. SECURITY CHALLENGES AND OPPORTUNITIES FOR SMART CONTRACTS IN INTERNET OF THINGS: A SURVEY
A. Fixing the Inherently Vulnerable Particularities
Observability: Knowing that issue, developers are required
to be more careful with their programming. It is necessary to
standardize the process of programming the smart contract
and detect the potential vulnerabilities of the code before
releasing it to minimize the risk of open-source contracts.
For the privacy protection of smart contracts, most researches
are improvements based on blockchain privacy, combining
multiple cryptographic technologies [25], [94], [95]. Hyper-
ledger Fabric has optimized access control and refined the
authority granularity of smart contract nodes. Different users
have specific authorities to deploy, query, or execute smart
contracts [45]. Besides, some researchers employ the trusted
execution environment (TEE) to preserve the privacy of smart
contracts while ensuring the integrity and availability of open-
source blockchain platforms [96].
Immutability: To tackle the issue of immutability, Marino
et al. [73] presented a series of standards to alter or repeal
smart contracts. Such standards are taken from contract law
and then redefined to fit in the context of smart contracts.
After being tested in Ethereum, these standards are proved
to be practicable. However, it is kind of against the original
design principles of Ethereum.
Lack of Trustworthy Data Feeds: Many researchers are
working on addressing the oracle problem to mitigate the trust
conflict between oracles and the trustless execution of smart
contracts. Zhang et al. [75] proposed a Town Crier (TC) solu-
tion, which includes a TC contract hosted on the blockchain
and a TC server outside the blockchain. To acquire the needed
external data, a user contract first sends a request to the TC
contract. Then the TC contract forwards it to the TC server,
and the server communicates with the external data sources
via HTTPS. Authors in [76] built multiple distributed oracle
servers for IoT using Intel SGX to support data availability
and integrity.
Randomness Generation: According to the official recom-
mendation of Solidity, contract developers can use third-party
services such as Oraclize to obtain safer random numbers.
In Oraclize, the random data is generated with a document
called authenticity proof. The authenticity proofs can build
upon secure element-based techniques such as auditable virtual
machines and TEEs [78].
Timestamp Dependence: Block timestamps should not
be the decisive factor (either directly or via derivation) for
changing an important state. Thus, it is recommended to use
safer items such as the fixed value of block.number [26] and
an average block time to estimate time in smart contracts,
because the block number is not as easy to be manipulated by
malicious miners.
Transaction-Ordering Dependence: To tackle this issue,
a guarantee is required that the result of an external call of a
smart contract is either an expected output or a failure, even
given the non-deterministic execution order of transactions.
Authors in [26] suggested a guard condition as a solution,
ensuring that the confirmation of each transaction is dependent
on the guard condition satisfaction, otherwise the transaction
will be discarded. Another suggestion for developers is to set
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
11
up a unique context for the output as a precondition to be
executed. Using logical clocks to order causally related events
in Ethereum is also a helpful tip.
Read after Write: Zhang et al. [79] analyzed the relation-
ship between the read set and write set between transactions
and then designed a cache layer between the distributed appli-
cation client and the Fabric network to address the potential
problem of non-deterministic transactions caused by read-
write conflicts. This cache layer guarantees that the conflicting
transactions must be waiting until the previous transactions are
committed.
B. Security Audit for Programming Vulnerabilities
Considering the uniqueness of its immutability and ob-
servability, it is significant for a smart contract to conduct
a comprehensive and in-depth code security audit to eliminate
vulnerabilities and reduce security risks to ensure the reliable
operation of the IoT businesses on the blockchain and protect
the safety of devices before it goes online. Smart contract
audit is a process of deploying the contract to the testnet,
carefully studying the code, reviewing vulnerabilities, errors
and risks, and then reporting how to amend it by experienced
audit personnel. However, it is worth noting that the audit
simply means that the contract code has been inspected by
experts and it is basically safe. No one can completely ensure
that the contract would not make mistakes or create bugs in
the future.
Here, we mainly discuss three commonly-used automated
audit methods, then introduce several representative tools
based on them.
Signature Matching: Signature matching, which comes
from the traditional anti-virus approach, is to extract the
abstract signatures from malicious code and then match the
signatures with new static code. A signature is the digital
fingerprint of a piece of malware. It is a unique string of bits,
a binary pattern representing the malware. The advantages of
this method are obvious. First, the audit is fast, because it is
just a string match to the source code. The second is that it
can respond quickly to new vulnerabilities, because this audit
method is often developed as a plug-in. If a new vulnerability
occurs, developers can quickly submit new matching patterns.
However, the false negative rate of signature matching is a
little high because some parts of the process are not consistent
with the traditional static code audit. In traditional static audit
methods (e.g., APP detection), developers will call relatively
stable functions from the library to audit. But functions and
signatures in smart contracts are more versatile.
SCaaS [97] is a smart contract audit engine through sig-
nature matching and machine learning techniques. It firstly
decomposes the contract code from syntax and semantic levels,
then classifies and identifies signatures by dynamic K-Means
clustering, and retrains the model with old and new additional
datasets through incremental learning. In [98], the author
proposed another audit solution. The solution translates the
EVM bytecode into RGB color code and transforms the color
code to a fixed sized encoded image. Then, the encoded image
is fed to the CNN for automatic signature extraction and
learning to detect compiler bugs in smart contracts.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
12
Formal Verification: Formal verification in software is
to verify the reliability of programs in a logical language,
that is, constructing abstract formal models such as state
machines or directed graphs for finite state programs, and
then verifying the abstract formulas by formal methods of
mathematics. The main approaches to implementing formal
verification consist of abstract interpretation, theorem proving
and model checking. In 2016, formal verification was intro-
duced to audit smart contracts by Bhargavan et al. [99]. They
translated Solidity into F* language to verify the functional
correctness of source level and decompiled EVM bytecode to
analyze low-level properties. In [100], the authors used logical
framework Isabelle/HOL to split the bytecode into basic
blocks when auditing the Ethereum smart contracts. Kalra et
al. [101] implemented abstract interpretation, model checking,
and constrained horn clauses to audit smart contracts quite
quickly. KEVM [102] was designed as an executable formal
specification of EVM bytecode built by the K framework,
serving as a solid foundation for further formal analysis.
Brent et al. [80] proposed Vandal to translate EVM bytecode
to logic semantic relations via abstract interpretation. Then
Vandal analyzes the logic relations to audit contracts and find
out vulnerabilities with the Soufflé language. Anastasia et
al. [103] presented an end-to-end framework, VeriSolid, which
provides graphical editors with distinct patterns to specificate
the transition systems and natural-like language templates for
formal security properties.
Basically, the formal verification of smart contracts includes
three steps: a) a formal description of the functions to be com-
pleted by the contract; c) a formal description of the contract
code; b) verification. This method provides more stringent
security for smart contracts while the level of automation is
lower, the cost is higher, and the research difficulty is greater.
Symbolic Execution: Symbolic execution [26] refers to a
method of program analysis to determine which input vectors
correspond to the result vector of a program. The core idea is
to use symbolic values to represent the input data of a pro-
gram, and to convert the operation process into mathematical
expressions by statements, to generate a symbolic execution
tree based on a control flow graph (CFG) and create a series
of symbolic expressions with input data as variables for each
path. During symbolic execution, whenever a judgment or a
jump statement is encountered, the symbolic execution tool
will collect all path constraints of the current execution path
into a constraint set. Specifically, a path constraint refers to the
value of the conditional branch associated with input symbols
in the program branch instruction. And a path constraint set
stores the constraints from each program path. Using the
constraint solver to solve the constraint set, the accessibility
of the path can be obtained. If the constraint solver has a
certain solution, that means the path is reachable, otherwise
the path is unreachable. In an ideal case with abundant time
and computing resources, symbolic execution can traverse all
the paths of the target program to judge the reachability of
these paths.
Oyente [26] was the first audit tool based on symbolic
execution. It can extract CFG from the EVM bytecode,
and symbolically execute it to detect vulnerability patterns.
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL
In [104], the EthIR framework was proposed to extend Oyente
for two purposes: a) to recover the list of addresses for uncon-
ditional blocks with more than one possible jump address (as
Oyente originally only kept the last processed one), and b) to
add more explicit information to the CFG. Another security
audit tool for smart contracts is Mythril [105]. Mythril adopts
multiple detecting techniques including the Concolic analysis,
taint analysis and control flow checking. The entire process
of analysis is based on a special symbolic execution library
designed for EVM bytecode called laser-Ethereum. Authors
in [92] implemented MAIAN for detecting greedy, prodigal
and suicidal behaviors of Ethereum smart contracts via inter-
procedural symbolic analysis and concrete validator. Manti-
core [106] is another symbolic execution tool that generates
inputs that trigger the particular program paths, tracks their
executions and discovers the vulnerable input with memory
security violations. Tsankov et al. [107] developed a fully
automated tool called Securify to symbolically identify critical
dependency graphs, extract the semantic information, and
prove the safety of contract patterns according to given prop-
erties. Krupp et al. [108] presented a more generic definition
of vulnerable contracts and built a symbolic execution tool
called teEther for automatic exploit generation based on this
definition. Zhou et al. [109] also proposed a tool called SASC
to detect six security risks through symbolic execution and
syntax analysis.
While symbolic execution is indeed a powerful generic
technique to facilitate contract auditing, it cannot traverse all
code paths and it takes longer running time for auditing a
smart contract than other methods.
In Table IV, we summarize the three audit methods and the
representative audit tools for these methods.
C. Countermeasures for Smart Contract Attacks for the IoT
Reentrancy Attack: We introduce two programming tech-
niques in Solidity that can help avoid potential reentrancy at-
tacks here. The first is to apply the Checks-Effects-Interactions
pattern [83], a way to make sure that all internal work such
as changing state variables finishes before calling any external
functions. In other words, this is a better programming pattern
for executing the external call at the end of a contract. The
second is to use a mutex [84] to alleviate the reentrancy
problem. A mutex is a state variable that locks several states of
the smart contract when it is being executed. Only the contract
owner can unlock the states.
Eclipse Attack: Researchers who found this attack have
come up with some countermeasures [86]. First, set an upper
limit on the number of incoming TCP connections to force all
clients to mix the incoming and outgoing TCP connections.
Another way is to ensure that each Ethereum network node
will almost always make the outgoing connections to various
other peers on the same network, limiting the actual number
of outgoing connections to comprehensively isolate legitimate
users from other users. Although they cannot completely
prevent the eclipse attack, they have expanded the number of
malicious nodes required to launch such attack from only two
to thousands. Fortunately, Ethereum developers have already
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
K. PENG et al.. SECURITY CHALLENGES AND OPPORTUNITIES FOR SMART CONTRACTS IN INTERNET OF THINGS: A SURVEY
TABLE IV: The summary of the common security audit methods.
Methods Main ideas
Extract the abstract signatures and
Signature
match the signatures with new static
matching
code
Construct abstract formal models for
Formal
finite state programs, then verify the
verifica-
abstract formulas by formal methods
tion
of mathematics
Use symbolic values to represent the
Symbolic
input data and convert the operation
execution
process into symbolic expressions
implemented corresponding patches to fix the problem. So
users only need to upgrade their clients to 1.8.1.
DoS Attack: In the first case, a feasible solution is to use
a time-lock. If the result of executing an external function
changes the state of the contract, developers should fore-
thoughtfully prepare to cope with the potential failures that
may occur and adopt a time-based state progression in the
contract to prevent DoS attacks. In the second case, users
should avoid using the operations that can be artificially
manipulated to reach the gas limit by external users. As for the
Ethereum developers, a more dynamic adjustment of gas cost
is necessary to thwart operations prone to DoS attacks [87].
RAMsomware attack: For developers and users, they
should be more careful with the source contract code and only
give their permission code to the trusted service providers.
Apart from that, authors in [88] suggested a fine-grained
permission control strategy which should ensure a user can
set a specific available period for the permission so that
the permission could be terminated anytime in case of the
RAMsomware attack.
V. C HALLENGES AND F UTURE D IRECTIONS
A. Challenges
Although there have been a number of real-world applica-
tions and security solutions, the usage of smart contracts for
the IoT is still in its infancy. We now discuss the remaining
challenges in tackling the security issues and some relevant
research directions in the future.
• Despite the diversity of security audit tools for smart
contracts, the security issues and processing capacity they
can handle vary greatly. Most audit tools can only detect
a small fraction of the known vulnerabilities and the
accuracy remains to be improved [74]. Besides, existing
tools are still neither fully automated nor efficient enough,
especially for mass use in IoT industries. There is still a
long way to go for shortening the audit time and reducing
the cost of them.
• To retain the transparency and supervisability of
blockchain, the transaction records and bytecode of
Ethereum-like smart contracts are also transparent [25].
These features could be inappropriate for the cases that
IoT users or service providers demand private contract
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
Things Journal
13
Pros Cons Representative tools
a) Short audit time
SCaaS [97],
b) Fast response High false negative rate
Color-inspired Inspection [98]
c) Easy to implement
F* Framework [99],
a) High cost
Low false negative Isabelle/HOL Framework [100],
b) Low-level automation
rate ZEUS [101], KEVM [102],
c) Difficult to implement
Vandal [80], VeriSolid [103]
Oyente [26], EthIR [104],
Low false negative Mythril [105], MAIAN [92],
Long audit time
rate Manticore [106], Securify [107],
teEther [108], SASC [109]
details and transactions since most IoT devices are
environment-detecting sensors that collect a huge amount
of users’ sensitive data. Apparently, this transparency also
attracts attackers a lot and creates a higher probability of
being attacked [19].
• For IoT devices with limited energy supply or constrained
environment, the communication between devices is in-
termittent. Therefore, when authorizing and verifying an
IoT device, it is common that the device is offline. This
situation may influnce the transmission of the information
flow involving smart contracts, even resulting in a tem-
porary suspension [110]. In actual application scenarios,
the lack of network connectivity may affect the correct
execution of the smart contract in traditional blockchain
platforms and lead to a great loss of money consequently.
• Since the technology of blockchain-based smart contracts
itself is still wildly understudied and very few real-world
killer applications of blockchains [32] and smart contracts
have been deployed in the IoT for a long time, we are
unaware of more practical security issues and how they
affect each part of the whole IoT system. Only time willl
let us know more about this topic.
B. Future Directions
From our viewpoint, there are some research directions for
improving the security of smart contracts for the IoT:
Empirical Evaluation of Security Audit Tools: The urgent
need for securing smart contracts in business has promoted the
prosperity and development of security audit tools. As men-
tioned above, their performances differ in accuracy, efficiency,
effectiveness, and so on. We notice the scarcity of compre-
hensive assessing experiments and literatures of security audit
tools for developers to refer to, especially concerning the IoT.
Hence, we are looking forward to more empirical research
works to fill this gap.
Smart Contract Encryption: The transaction contents of
the trading participants, contract code, as well as the execution
process of decentralized applications are of great value to IoT
service providers and users. Therefore, the implementation of
privacy-preserving smart contracts indicates a more reliable
and economic IoT system in the real world. Many encryption
techniques are able to protect the security of private data
involved in smart contracts, such as TEEs [96], homomorphic
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
14
encryption, ring signature, and zero-knowledge proof [25].
Researchers should figure out how to use these techniques
and take into account limited IoT resources to provide a
blockchain-based IoT system with secure, reliable and con-
venient private smart contract execution capabilities.
Adoption of Suitable Communication Protocols: Smart
contracts need to communicate with a third-party system
or other IoT devices to execute their functions. Facing the
intermittent connectivity issue, the blockchain system should
get recovered from the network failure by aggregating the data
from different subnets in a short time. One potential direction
is to utilize Named Data Networking (NDN), a new type
of network architecture that supports features including in-
network caching and built-in content multicast to improve the
efficiency of data delivery for intermittent IoT networks [111].
Regulation of Programming Languages: In case of the
potential high security risks of programming the smart con-
tracts [72], it is of vital importance to summarize the excellent
models of smart contracts, develop standard smart contract
templates, and standardize the grammatical and semantic for-
mats of programming languages (if necessary, to design new
secure languages) and the writing of smart contracts with
certain regulations to improve the quality and security of smart
contracts.
VI. C ONCLUSION
With the rapidly proliferating IoT applications, the devel-
opment of effective and efficient smart contract mechanisms
with enhanced security is a new and active field which will
continue to thrive. In this survey, we present the security
issues, corresponding solutions, research challenges as well
as future directions in the integration between smart contracts
and the IoT for the first time, with a focus on three important
aspects: inherently vulnerable particularities, programming
vulnerabilities, and feasible attacks.
Looking into the future, we have some advice for both de-
velopers and IoT project parties. For developers, it is necessary
to fully realize that the actual operating environment of the
contract being written is an untrusted distributed environment.
Therefore, it is crucial to well balance the development speed
and security. During the process of the development, a reward
mechanism can be introduced in the early days to allow
hackers or community members to jointly discover the vul-
nerabilities. For IoT project parties, it is necessary to provide
sufficient security training for smart contract developers to
ensure security awareness during development. The design of
smart contracts also requires the deep involvement of security
personnel, preferably in design, development, and testing.
At last, do not forget to ensure sufficient resources in code
auditing and security testing, which are inner consistency with
the objective of this survey.
R EFERENCES
[1] A. Zanella, N. Bui, A. Castellani, L. Vangelista, and M. Zorzi, “Internet
of Things for smart cities,” IEEE Internet of Things Journal, vol. 1,
no. 1, pp. 22–32, Feb. 2014.
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL
[2] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and
M. Ayyash, “Internet of Things: A survey on enabling technologies,
protocols, and applications,” IEEE Communications Surveys & Tutori-
als, vol. 17, no. 4, pp. 2347–2376, Jun. 2015.
[3] H. Jiang, J. Li, P. Zhao, F. Zeng, Z. Xiao, and A. Iyengar, “Location
privacy-preserving mechanisms in location-based services: A compre-
hensive survey,” ACM Computing Surveys, vol. 54, no. 1, pp. 1–36,
2021.
[4] M. Mohsin, Z. Anwar, F. Zaman, and E. Al-Shaer, “IoTChecker: A
data-driven framework for security analytics of Internet of Things
configurations,” Computers & Security, vol. 70, pp. 199–223, Sep.
2017.
[5] J. Lin, W. Yu, N. Zhang, X. Yang, H. Zhang, and W. Zhao, “A survey
on Internet of Things: Architecture, enabling technologies, security and
privacy, and applications,” IEEE Internet of Things Journal, vol. 4,
no. 5, pp. 1125–1142, Oct. 2017.
[6] T. Qiu, N. Chen, K. Li, M. Atiquzzaman, and W. Zhao, “How can
heterogeneous Internet of Things build our future: A survey,” IEEE
Communications Surveys & Tutorials, vol. 20, no. 3, pp. 2011–2027,
Feb. 2018.
[7] N. Kshetri, “Can blockchain strengthen the Internet of Things?” IT
Professional, vol. 19, no. 4, pp. 68–72, Aug. 2017.
[8] M. T. Hammi, B. Hammi, P. Bellot, and A. Serhrouchni, “Bubbles of
trust: A decentralized blockchain-based authentication system for IoT,”
Computers & Security, vol. 78, pp. 126–142, Jun. 2018.
[9] Y. Sun, L. Zhang, G. Feng, B. Yang, B. Cao, and M. A. Imran,
“Blockchain-enabled wireless Internet of Things: Performance analysis
and optimal communication node deployment,” IEEE Internet of Things
Journal, vol. 6, no. 3, pp. 5791–5802, Jun. 2019.
[10] “Blockchain for smart communities: Applications, challenges and op-
portunities,” Journal of Network and Computer Applications, vol. 144,
pp. 13 – 48, Jun. 2019.
[11] G. Ali, N. Ahmad, Y. Cao, M. Asif, H. Cruickshank, and Q. E. Ali,
“Blockchain based permission delegation and access control in Internet
of Things (BACI),” Computers & Security, vol. 86, pp. 318–334, Jun.
2019.
[12] J. Qiu, D. Grace, G. Ding, J. Yao, and Q. Wu, “Blockchain-based
secure spectrum trading for unmanned-aerial-vehicle-assisted cellular
networks: An operator’s perspective,” IEEE Internet of Things Journal,
vol. 7, no. 1, pp. 451–466, 2020.
[13] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” https:
//bitcoin.org/bitcoin.pdf, 2008.
[14] E. F. Jesus, V. R. Chicarino, C. V. de Albuquerque, and A. A. d. A.
Rocha, “A survey of how to use blockchain to secure internet of things
and the stalker attack,” Security and Communication Networks, vol.
2018, Apr. 2018.
[15] M. Wu, K. Wang, X. Cai, S. Guo, M. Guo, and C. Rong, “A
comprehensive survey of blockchain: from theory to IoT applications
and beyond,” IEEE Internet of Things Journal, vol. 6, no. 5, pp. 8114–
8154, Oct. 2019.
[16] W. Dai, C. Daia, K. R. Choo, C. Cui, D. Zou, and H. Jin, “SDTE: A
secure blockchain-based data trading ecosystem,” IEEE Transactions
on Information Forensics and Security, vol. 15, pp. 725–737, 2020.
[17] J.-S. Park, T.-Y. Youn, H.-B. Kim, K.-H. Rhee, and S.-U. Shin, “Smart
contract-based review system for an IoT data marketplace,” Sensors,
vol. 18, no. 10, p. 3577, Oct. 2018.
[18] Y. Zhang, S. Kasahara, Y. Shen, X. Jiang, and J. Wan, “Smart contract-
based access control for the Internet of Things,” IEEE Internet of
Things Journal, vol. 6, no. 2, pp. 1594–1605, Apr. 2019.
[19] Y. Hanada, L. Hsiao, and P. Levis, “Smart contracts for machine-
to-machine communication: Possibilities and limitations,” in Proc. of
International Conference on Internet of Things and Intelligence System
(IOTAIS), Nov. 2018, pp. 130–136.
[20] S. Ali, G. Wang, M. Z. A. Bhuiyan, and H. Jiang, “Se-
cure data provenance in cloud-centric internet of things via
blockchain smart contracts,” in Proc. of SmartWorld, Ubiquitous
Intelligence & Computing, Advanced & Trusted Computing, Scal-
able Computing & Communications, Cloud & Big Data Com-
puting, Internet of People and Smart City Innovation (Smart-
World/SCALCOM/UIC/ATC/CBDCom/IOP/SCI), Oct. 2018, pp. 991–
998.
[21] X. Huang, D. Ye, R. Yu, and L. Shu, “Securing parked vehicle assisted
fog computing with blockchain and optimal smart contract design,”
IEEE/CAA Journal of Automatica Sinica, vol. 7, no. 2, pp. 426–441,
Mar. 2020.
[22] N. Szabo, “Formalizing and securing relationships on public networks,”
First Monday, vol. 2, no. 9, Sep. 1997.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
K. PENG et al.. SECURITY CHALLENGES AND OPPORTUNITIES FOR SMART CONTRACTS IN INTERNET OF THINGS: A SURVEY
[23] V. Buterin, “A next-generation smart contract and decentralized appli-
cation platform,” https://github.com/ethereum/wiki/wiki/White-Paper,
2016.
[24] S. Wang, L. Ouyang, Y. Yuan, X. Ni, X. Han, and F.-Y. Wang,
“Blockchain-enabled smart contracts: Architecture, applications, and
future trends,” IEEE Transactions on Systems, Man, and Cybernetics:
Systems, vol. 49, no. 11, pp. 2266–2277, Nov. 2019.
[25] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk:
The blockchain model of cryptography and privacy-preserving smart
contracts,” in Proc. of IEEE S&P, May 2016, pp. 839–858.
[26] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart
contracts smarter,” in Proc. of ACM CCS, Oct. 2016, pp. 254–269.
[27] X. Li, P. Jiang, T. Chen, X. Luo, and Q. Wen, “A survey on the security
of blockchain systems,” Future Generation Computer Systems, vol.
107, pp. 841–853, Jun. 2020.
[28] K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts
for the Internet of Things,” IEEE Access, vol. 4, pp. 2292–2303, May
2016.
[29] N. Atzei, M. Bartoletti, and T. Cimoli, “A survey of attacks on ethereum
smart contracts,” in Proc. of International Conference on Principles of
Security and Trust, Mar. 2017, pp. 164–186.
[30] A. Dika, “Ethereum smart contracts: Security vulnerabilities and secu-
rity tools,” Master’s thesis, NTNU, 2017.
[31] M. Alharby and A. Van Moorsel, “Blockchain-based smart contracts:
A systematic mapping study of academic research (2018),” in Proc.
of International Conference on Cloud Computing, Big Data and
Blockchain (ICCBB), Nov. 2018, pp. 1–6.
[32] N. Fotiou and G. C. Polyzos, “Smart contracts for the Internet of
Things: Opportunities and challenges,” in Proc. of European Confer-
ence on Networks and Communications, Jun. 2018, pp. 256–260.
[33] M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. Maglaras,
and H. Janicke, “Blockchain technologies for the Internet of Things:
Research issues and challenges,” IEEE Internet of Things Journal,
vol. 6, no. 2, pp. 2188–2204, Apr. 2019.
[34] J. Liu and Z. Liu, “A survey on security verification of blockchain
smart contracts,” IEEE Access, vol. 7, pp. 77 894–77 904, Jun. 2019.
[35] S. Rouhani and R. Deters, “Security, performance, and applications of
smart contracts: A systematic survey,” IEEE Access, vol. 7, pp. 50 759–
50 779, Apr. 2019.
[36] M. Di Angelo and G. Salzer, “A survey of tools for analyzing
ethereum smart contracts,” in Proc. of IEEE International Conference
on Decentralized Applications and Infrastructures (DAPPCON), Apr.
2019, pp. 69–78.
[37] M. Demir, M. Alalfi, O. Turetken, and A. Ferworn, “Security smells
in smart contracts,” in Proc. of IEEE 19th International Conference on
Software Quality, Reliability and Security Companion (QRS-C), Jul.
2019, pp. 442–449.
[38] K. Yamashita, Y. Nomura, E. Zhou, B. Pi, and S. Jun, “Potential risks
of hyperledger fabric smart contracts,” in Proc. of IEEE International
Workshop on Blockchain Oriented Software Engineering, Feb. 2019,
pp. 1–10.
[39] G. Schmitt, A. Mladenow, C. Strauss, and M. Schaffhauser-Linzatti,
“Smart contracts and Internet of Things: A qualitative content analysis
using the technology-organization-environment framework to identify
key-determinants,” Procedia Computer Science, vol. 160, pp. 189–196,
Sep. 2019.
[40] S. Sayeed, H. Marco-Gisbert, and T. Caira, “Smart contract: Attacks
and protections,” IEEE Access, vol. 8, pp. 24 416–24 427, Jan. 2020.
[41] Z. Zheng, S. Xie, H.-N. Dai, W. Chen, X. Chen, J. Weng, and M. Imran,
“An overview on smart contracts: Challenges, advances and platforms,”
Future Generation Computer Systems, vol. 105, pp. 475–491, Apr.
2020.
[42] A. López Vivar, A. T. Castedo, A. L. Sandoval Orozco, and L. J.
Garcı́a Villalba, “An analysis of smart contracts security threats along-
side existing solutions.” Entropy, vol. 22, no. 2, pp. 203–203, Feb.
2020.
[43] Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang, “An overview of
blockchain technology: Architecture, consensus, and future trends,” in
Proc. of IEEE International Congress on Big Data, Jun. 2017, pp.
557–564.
[44] S. Wan, M. Li, G. Liu, and C. Wang, “Recent advances in consensus
protocols for blockchain: a survey,” Wireless Networks, vol. 26, no. 8,
pp. 5579C–5593, Nov. 2020.
[45] C. Cachin et al., “Architecture of the hyperledger blockchain fabric,”
in Proc. of Workshop on distributed cryptocurrencies and consensus
ledgers, vol. 310, no. 4, 2016.
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
15
[46] E. IO, “EOS. IO technical white paper,” EOS. IO (accessed 18
December 2017) https://github.com/EOSIO/Documentation, 2017.
[47] T. Foundation, “TRON technical white paper v2.0,” TRON Foundation
(accessed 10 December 2018) https://tron.network/static/doc/, 2018.
[48] R. Alexander, IOTA - Introduction to the Tangle Technology: Every-
thing You Need to Know about the Revolutionary Blockchain Alterna-
tive. Independently published, 2018.
[49] Y. Yu, Y. Li, J. Tian, and J. Liu, “Blockchain-based solutions to
security and privacy issues in the Internet of Things,” IEEE Wireless
Communications, vol. 25, no. 6, pp. 12–18, Dec. 2018.
[50] M. N. Islam and S. Kundu, “Preserving IoT privacy in sharing economy
via smart contract,” in Proc. of IEEE International Conference on
Internet-of-Things Design and Implementation (IoTDI), Apr. 2018, pp.
296–297.
[51] S. Wang, Y. Yuan, X. Wang, J. Li, R. Qin, and F.-Y. Wang, “An
overview of smart contract: architecture, applications, and future
trends,” in Proc. of IEEE Intelligent Vehicles Symposium, Jun. 2018,
pp. 108–113.
[52] A. F. Zorzo, H. C. Nunes, R. C. Lunardi, R. A. Michelin, and S. S.
Kanhere, “Dependable IoT using blockchain-based technology,” in
Proc. of 8th Latin-American Symposium on Dependable Computing,
Oct. 2018, pp. 1–9.
[53] G. Ramezan and C. Leung, “A blockchain-based contractual routing
protocol for the Internet of Things using smart contracts,” Wireless
Communications and Mobile Computing, vol. 2018, Nov. 2018.
[54] Z. Shae and J. Tsai, “Transform blockchain into distributed parallel
computing architecture for precision medicine,” in Proc. of 38th
International Conference on Distributed Computing Systems (ICDCS),
Jul. 2018, pp. 1290–1299.
[55] I. Psaras, “Decentralised edge-computing and IoT through distributed
trust,” in Proc. of 16th International Conference on Mobile Systems,
Applications, and Services, Jun. 2018, pp. 505–507.
[56] J. Pan, J. Wang, A. Hester, I. Alqerm, Y. Liu, and Y. Zhao, “Edgechain:
An edge-IoT framework and prototype based on blockchain and smart
contracts,” IEEE Internet of Things Journal, vol. 6, no. 3, pp. 4719–
4732, Jun. 2019.
[57] S. Chen, R. Shi, Z. Ren, J. Yan, Y. Shi, and J. Zhang, “A blockchain-
based supply chain quality management framework,” in Proc. of 14th
IEEE International Conference on e-Business Engineering (ICEBE),
Nov. 2017, pp. 172–176.
[58] R. Casado-Vara, J. Prieto, F. De la Prieta, and J. M. Corchado, “How
blockchain improves the supply chain: Case study alimentary supply
chain,” Procedia computer science, vol. 134, pp. 393–398, Jul. 2018.
[59] A. Alahmadi and X. Lin, “Towards secure and fair IoT-enabled supply
chain management via blockchain-based smart contracts,” in Proc. of
IEEE International Conference on Communications (ICC), May 2019,
pp. 1–7.
[60] L. Augusto, R. Costa, J. Ferreira, and R. Jardim-Gonçalves, “An
application of ethereum smart contracts and IoT to logistics,” in Proc.
of IEEE International Young Engineers Forum (YEF-ECE), May 2019,
pp. 1–7.
[61] H. Moudoud, S. Cherkaoui, and L. Khoukhi, “An IoT blockchain
architecture using oracles and smart contracts: The use-case of a food
supply chain,” in Proc. of 30th IEEE Annual International Symposium
on Personal, Indoor and Mobile Radio Communications (PIMRC), Sep.
2019, pp. 1–6.
[62] S. E. Chang, Y.-C. Chen, and M.-F. Lu, “Supply chain re-engineering
using blockchain technology: A case of smart contract based tracking
process,” Technological Forecasting and Social Change, vol. 144, pp.
1–11, Jul. 2019.
[63] M. A. Ferrag, L. Shu, X. Yang, A. Derhab, and L. Maglaras, “Security
and privacy for green IoT-based agriculture: Review, blockchain solu-
tions, and challenges,” IEEE Access, vol. 8, pp. 32 031–32 053, Feb.
2020.
[64] T. Bocek, B. B. Rodrigues, T. Strasser, and B. Stiller, “Blockchains
everywhere-a use-case of blockchains in the pharma supply-chain,” in
Proc. of IFIP/IEEE Symposium on Integrated Network and Service
Management, May 2017, pp. 772–777.
[65] A. S. Omar and O. Basir, “Identity management in IoT networks using
blockchain and smart contracts,” in Proc. of 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), Aug. 2018,
pp. 994–1000.
[66] N. Fotiou, I. Pittaras, V. A. Siris, S. Voulgaris, and G. C. Polyzos,
“Secure IoT access at scale using blockchains and smart contracts,” in
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
16
Proc. of 20th IEEE International Symposium on” A World of Wireless,
Mobile and Multimedia Networks”(WoWMoM), Jun. 2019, pp. 1–6.
[67] V. A. Siris, D. Dimopoulos, N. Fotiou, S. Voulgaris, and G. C. Polyzos,
“Trusted D2D-based IoT resource access using smart contracts,” in
Proc. of 20th IEEE International Symposium on” A World of Wireless,
Mobile and Multimedia Networks”(WoWMoM), Jun. 2019, pp. 1–9.
[68] T. Sultana, A. Almogren, M. Akbar, M. Zuair, I. Ullah, and N. Javaid,
“Data sharing system integrating access control mechanism using
blockchain-based smart contracts for IoT devices,” Applied Sciences,
vol. 10, no. 2, p. 488, Jan. 2020.
[69] Y. Nakamura, Y. Zhang, M. Sasabe, and S. Kasahara, “Exploiting smart
contracts for capability-based access control in the Internet of Things,”
Sensors, vol. 20, no. 6, p. 1793, Mar. 2020.
[70] K. Košt’ál, P. Helebrandt, M. Belluš, M. Ries, and I. Kotuliak, “Man-
agement and monitoring of IoT devices using blockchain,” Sensors,
vol. 19, no. 4, p. 856, Feb. 2019.
[71] S. Huh, S. Cho, and S. Kim, “Managing IoT devices using blockchain
platform,” in Proc. of International Conference on Advanced Commu-
nication Technology, Feb. 2017, pp. 464–467.
[72] R. M. Parizi, A. Dehghantanha et al., “Smart contract programming
languages on blockchains: An empirical evaluation of usability and
security,” in Proc. of International Conference on Blockchain, Jun.
2018, pp. 75–91.
[73] B. Marino and A. Juels, “Setting standards for altering and undoing
smart contracts,” in Proc. of International Symposium on Rules and
Rule Markup Languages for the Semantic Web, Jun. 2016, pp. 151–
166.
[74] A. Mense and M. Flatscher, “Security vulnerabilities in ethereum smart
contracts,” in Proc. of 20th International Conference on Information
Integration and Web-based Applications & Services, Nov. 2018, pp.
375–380.
[75] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier:
An authenticated data feed for smart contracts,” in Proc. of ACM CCS,
Oct. 2016, pp. 270–282.
[76] S. Woo, J. Song, and S. Park, “A distributed oracle using Intel SGX for
blockchain-based IoT applications,” Sensors, vol. 20, no. 9, p. 2725,
May 2020.
[77] C. Pierrot and B. Wesolowski, “Malleability of the blockchain’s en-
tropy,” Cryptography and Communications, vol. 10, no. 1, pp. 211–233,
Jan. 2018.
[78] “Oraclize docs,” http://docs.oraclize.it/, 2019.
[79] S. Zhang, E. Zhou, B. Pi, J. Sun, K. Yamashita, and Y. Nomura, “A
solution for the risk of non-deterministic transactions in hyperledger
fabric,” in Proc. of IEEE International Conference on Blockchain and
Cryptocurrency (ICBC), May 2019, pp. 253–261.
[80] L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V. Gramoli,
R. Holz, and B. Scholz, “Vandal: A scalable security analysis frame-
work for smart contracts,” CoRR, arXiv:1809.03981, 2018.
[81] N. He, R. Zhang, L. Wu, H. Wang, X. Luo, Y. Guo, T. Yu,
and X. Jiang, “Security analysis of EOSIO smart contracts,” CoRR,
arXiv:2003.06568, 2020.
[82] M. Rodler, W. Li, G. O. Karame, and L. Davi, “Sereum: Protecting
existing smart contracts against re-entrancy attacks,” in Proc. of 26th
Annual Network and Distributed System Security Symposium, Feb.
2019.
[83] “Solidity docs,” https://solidity.readthedocs.io/en/v0.4.21/
security-considerations.html/, 2019.
[84] “Smart contract best practices,” https://consensys.github.io/
smart-contract-best-practices/, 2016.
[85] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse attacks
on bitcoin’s peer-to-peer network,” in Proc. of USENIX Security
Symposium, Aug. 2015, pp. 129–144.
[86] Y. Marcus, E. Heilman, and S. Goldberg, “Low-resource eclipse attacks
on ethereum’s peer-to-peer network,” IACR Cryptology ePrint Archive,
pp. 236–240, 2018.
[87] T. Chen, X. Li, Y. Wang, J. Chen, Z. Li, X. Luo, M. H. Au, and
X. Zhang, “An adaptive gas cost mechanism for ethereum to defend
against under-priced dos attacks,” in Proc. of International Conference
on Information Security Practice and Experience, Dec. 2017, pp. 3–24.
[88] S. Lee, D. Kim, D. Kim, S. Son, and Y. Kim, “Who spent my {EOS}?
on the (in) security of resource management of eos.io,” in Proc. of 13th
{USENIX} Workshop on Offensive Technologies, Aug. 2019.
[89] Microsoft, “The stride threat model,” https://docs.microsoft.com/en-us/
previous-versions/commerce-server/ee823878(v=cs.20), 2021.
2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL
[90] F. Alkurdi, I. Elgendi, K. S. Munasinghe, D. Sharma, and A. Ja-
malipour, “Blockchain in IoT security: a survey,” in Proc. of 28th
IEEE International Telecommunication Networks and Applications
Conference (ITNAC), Nov. 2018, pp. 1–4.
[91] G. Caldarelli, C. Rossignoli, and A. Zardini, “Overcoming the
blockchain oracle problem in the traceability of non-fungible products,”
Sustainability, vol. 12, no. 6, p. 2391, Mar. 2020.
[92] I. Nikolić, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, “Finding the
greedy, prodigal, and suicidal contracts at scale,” in Proc. of Annual
Computer Security Applications Conference, Dec. 2018, pp. 653–663.
[93] T. Kumar, A. Braeken, V. Ramani, I. Ahmad, E. Harjula, and M. Yliant-
tila, “SEC-BlockEdge: Security threats in blockchain-edge based indus-
trial IoT networks,” in Proc. of IEEE 11th International Workshop on
Resilient Networks Design and Modeling (RNDM), Oct. 2019, pp. 1–7.
[94] B. Bünz, S. Agrawal, M. Zamani, and D. Boneh, “Zether: Towards
privacy in a smart contract world,” in Proc. of International Conference
on Financial Cryptography and Data Security, Jul. 2020, pp. 423–443.
[95] S. Steffen, B. Bichsel, M. Gersbach, N. Melchior, P. Tsankov, and
M. Vechev, “zkay: Specifying and enforcing data privacy in smart
contracts,” in Proc. of ACM SIGSAC Conference on Computer and
Communications Security, Nov. 2019, pp. 1759–1776.
[96] R. Yuan, Y.-B. Xia, H.-B. Chen, B.-Y. Zang, and J. Xie, “Shadoweth:
Private smart contract on public blockchain,” Journal of Computer
Science and Technology, vol. 33, no. 3, pp. 542–556, May 2018.
[97] “Codefine,” http://www.codefine.io/, 2018.
[98] T. H.-D. Huang, “Hunting the ethereum smart contract: Color-inspired
inspection of potential attacks,” CoRR, arXiv:1807.01868, 2018.
[99] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi,
G. Gonthier, N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote,
N. Swamy et al., “Formal verification of smart contracts: Short paper,”
in Proc. of ACM Workshop on Programming Languages and Analysis
for Security, Oct. 2016, pp. 91–96.
[100] S. Amani, M. Bégel, M. Bortin, and M. Staples, “Towards verifying
ethereum smart contract bytecode in Isabelle/HOL,” in Proc. of ACM
SIGPLAN International Conference on Certified Programs and Proofs,
Jan. 2018, pp. 66–77.
[101] S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: Analyzing safety
of smart contracts,” in Proc. of 25th Annual Network and Distributed
System Security Symposium, Feb. 2018, pp. 18–21.
[102] E. Hildenbrandt, M. Saxena, N. Rodrigues, X. Zhu, P. Daian, D. Guth,
B. Moore, D. Park, Y. Zhang, A. Stefanescu et al., “KEVM: A complete
formal semantics of the ethereum virtual machine,” in Proc. of 31st
IEEE Computer Security Foundations Symposium, Jul. 2018, pp. 204–
217.
[103] A. Mavridou, A. Laszka, E. Stachtiari, and A. Dubey, “VeriSolid:
Correct-by-design smart contracts for ethereum,” CoRR,
arXiv:1901.01292, 2019.
[104] E. Albert, P. Gordillo, B. Livshits, A. Rubio, and I. Sergey, “EthIR:
A framework for high-level analysis of ethereum bytecode,” in Proc.
of International Symposium on Automated Technology for Verification
and Analysis, Sep. 2018, pp. 513–520.
[105] B. Mueller, “Smashing ethereum smart contracts for fun and real
profit,” in Proc. of 9th Annual HITB Security Conference, 2018.
[106] T. of Bits, “Manticore: Symbolic execution for humans,” https://github.
com/trailofbits/manticore, 2017.
[107] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and
M. Vechev, “Securify: Practical security analysis of smart contracts,” in
Proc. of ACM SIGSAC Conference on Computer and Communications
Security, Oct. 2018, pp. 67–82.
[108] J. Krupp and C. Rossow, “teEther: Gnawing at ethereum to auto-
matically exploit smart contracts,” in Proc. of 27th USENIX Security
Symposium, Aug. 2018, pp. 1317–1333.
[109] E. Zhou, S. Hua, B. Pi, J. Sun, Y. Nomura, K. Yamashita, and
H. Kurihara, “Security assurance for smart contract,” in Proc. of 9th
IFIP/IEEE International Conference on New Technologies, Mobility
and Security, Feb. 2018, pp. 1–5.
[110] A. Taherkordi and P. Herrmann, “Pervasive smart contracts for
blockchains in IoT systems,” in Proc. of International Conference on
Blockchain Technology and Application, Dec. 2018, pp. 6–11.
[111] O. Attia, I. Khoufi, A. Laouiti, and C. Adjih, “An IoT-blockchain
architecture based on hyperledger framework for healthcare monitoring
application,” in Proc. of 10th IFIP International Conference on New
Technologies, Mobility and Security (NTMS), Jun. 2019, pp. 1–5.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2021.3074544, IEEE Internet of
Things Journal
K. PENG et al.. SECURITY CHALLENGES AND OPPORTUNITIES FOR SMART CONTRACTS IN INTERNET OF THINGS: A SURVEY 17

Kai Peng received the B.S., M.S., and Ph.D. degrees
from Huazhong University of Science and Technol-
ogy, China, in 1999, 2002, and 2006, respectively.
He is now the faculty of Huazhong University of
Science and Technology as a full professor. His
current research interests are in the areas of wireless
networking and big data processing.
Meijun Li received the B.E. degree from Wuhan
University of Technology, China, in 2018. She is
currently pursuing the M.S. degree in Electronics
and Information Engineering at Huazhong Univer-
sity of Science and Technology, China. Her research
interests include blockchain and Internet of Things.
Kim-Kwang Raymond Choo received the Ph.D.
degree in information security from the Queens-
land University of Technology, Australia, in 2006.
He currently holds the Cloud Technology Endowed
Professorship with The University of Texas at San
Antonio (UTSA). In 2016, he was named the Cyber-
security Educator of the Year (APAC). He and his
team won the Digital Forensics Research Challenge
organized by Germany’s University of Erlangen-
Nuremberg, in 2015. He was a recipient of the 2008
Australia Day Achievement Medallion, the British
Computer Society’s Wilkes Award, in 2008, the Fulbright Scholarship, in
2009, the 2014 Highly Commended Award by the Australia New Zealand
Policing Advisory Agency, the 2014 Highly Commended Award by the
Australia New Zealand Policing Advisory Agency, the ESORICS 2015 Best
Research Paper Award, the IEEE TrustCom 2018 Best Paper Award, the 2018
UTSA College of Business Col. Jean Piccione and Lt. Col. Philip Piccione
Endowed Research Award for Tenured Faculty, the 2019 IEEE Technical
Committee on Scalable Computing (TCSC) Award for Excellence in Scalable
Computing (Middle Career Researcher), the Outstanding Associate Editor of
2018 for IEEE Access, the British Computer Society’s 2019 Wilkes Award
Runner-Up, the 2019 EURASIP Journal on Wireless Communications and
Networking (JWCN) Best Paper Award, the Korea Information Processing
Society’s Journal of Information Processing Systems (JIPS) Survey Paper
Award (Gold) 2019, and the IEEE Blockchain 2019 Outstanding Paper Award.
He is a senior member of IEEE.

Haojun Huang received the B.S. degree from

the School of Computer Science and Technology,
Wuhan University of Technology, China, in 2005,
and the Ph.D. degree in School of Communication
and Information Engineering, University of Elec-
tronic Science and Technology, China, in 2012. He
was a post-doctoral researcher with the Research
Institute of Information Technology, Tsinghua Uni-
versity, Beijing, from 2012 to 2015, and an assistant
professor with Wuhan University, China, from 2015
to 2017. He is currently an associate professor at
Huazhong University of Science and Technology, China. His research interests
include wireless networks, big data, and software-defined networking.

Chen Wang (S’10-M’13-SM’19) received the B.S.

and Ph.D. degrees from the Department of Au-
tomation, Wuhan University, China, in 2008 and
2013, respectively. From 2013 to 2017, he was a
postdoctoral research fellow in the Networked and
Communication Systems Research Lab, Huazhong
University of Science and Technology, China. There-
after, he joined the faculty of Huazhong University
of Science and Technology where he is currently
an associate professor. His research interests are in
the broad areas of wireless networking, Internet of
Things, and mobile computing, with a recent focus on privacy issues in
wireless and mobile systems. He is a senior member of IEEE and ACM.

Shaohua Wan received the joint Ph.D. degree from

the School of Computer, Wuhan University and the
Department of Electrical Engineering and Computer
Science, Northwestern University, USA in 2010.
Since 2015, he has been holding a post-doctoral
position at the State Key Laboratory of Digital Man-
ufacturing Equipment and Technology, Huazhong
University of Science and Technology. From 2016 to
2017, he was a visiting professor at the Department
of Electrical and Computer Engineering, Technical
University of Munich, Germany. He is currently an
associate professor with the School of Information and Safety Engineering,
Zhongnan University of Economics and Law. His main research interests
include deep learning for Internet of Things and edge computing. He is an
author of over 80 peer-reviewed research papers and books. He is a senior
member of IEEE.

2327-4662 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: SARDAR VALLABHBHAI NATIONAL INSTITUTE OF TECH. Downloaded on April 21,2021 at 04:53:55 UTC from IEEE Xplore. Restrictions apply.