Indonesian J our nal of Electrical Engineering and Computer Science V ol. 37, No. 2, February 2025, pp. 1209 ∼ 1224 ISSN: 2502-4752, DOI: 10.11591/ijeecs.v37.i2.pp1209-1224 ❒ 1209 Na vigating the smart contract thr eat landscape: a systematic r e view Unyime Uf ok Ibekwe 1 , Uche M. Mbanaso 2 , Nw ojo Agwu Nnanna 1 , Umar Adam Ibrahim 3 1 Department of Computer Science, Nile Uni v ersity of Nigeria, Ab uja, Nigeria 2 Center for Cyberspace Studies, Nasara w a State Uni v ersity , K ef , Nigeria 3 Softw are Engineering and Information T echnology Department, Nile Uni v ersity of Nigeria, Ab uja, Nigeria Article Inf o Article history: Recei v ed May 2, 2024 Re vised Sep 11, 2024 Accepted Sep 30, 2024 K eyw ords: Blockchain Cyberattacks Cybersecurity Smart contracts V ulnerability ABSTRA CT Smart contracts ha v e emer ged as a transformati v e technology within the blockchain ecosystem, f acilitating the automated and trustless e x ecution of agreements. Their adoption spans di v erse sectors such as education, agriculture, healthcare, go v ernment, real estate, transportation, supply chain, and global ini- tiati v es lik e Central Bank Digital Currencies (CBDCs). Ho we v er , the security of smart contracts has become a signicant concern, as vulnerabilities in their de- sign and implementation can lead to se v ere consequences such as nancial losses and system f ailures. T his systematic re vie w consolidates ndings from 78 se- lected research articles, identifyi ng k e y vulnerabiliti es af fecting smart contracts and cate gorizing them into a taxonomy encompassing code-le v el, en vironment- dependent, and user -related vulnerabilities. It also e xam ines the threats that e xploit these vulnerabilities and the most ef fecti v e detection techniques. The domain-based classication presented in this re vie w aims to assist researchers, softw are engineers, and de v elopers in identifying and mitig ating signicant se- curity a ws related to the design, implementation, and depl o yment of smart con- tracts. A comprehensi v e understanding of these issues is essential for enhancing the security and reliability of the blockchain ecosystem, ultimately fostering the de v elopment of more secure and rob ust decentralized applications for end users. This is an open access article under the CC BY -SA license . Corresponding A uthor: Un yime Ufok Ibekwe Department of Computer Science, Nile Uni v ersity of Nigeria Plot 681, Cadastral Zone C, OO, Research and Institution Area Airport Road, Jabi, Ab uja, Nigeria Email: 211333010@nileuni v ersity .edu.ng 1. INTR ODUCTION Blockchain technology , kno wn for its decentralized and transparent nature has transformed the w ay transactions and agreements are conducted. It functions as a distrib uted ledger composed of interconnected blocks, cryptographically link ed together with each acti v e node on the netw ork maintaining a local cop y of all transactions [1] to ensure transparenc y and security . Originally de v eloped to enhance nancial transactions within the B itcoin netw ork [2], blockchain has g ained widespread attention and is no w adopted across v arious industries including supply chain management, record k eeping, and identity management [3]. Central to man y blockchain platforms are smart contracts, which are self-e x ecuting codes that au- tomatically carry out tas ks when specic predened conditions are met [4], thereby eli minating the need for intermediaries. Unlik e traditional agreements that rely on trusted third parties and arbitration, blockchain-based J ournal homepage: http://ijeecs.iaescor e .com Evaluation Warning : The document was created with Spire.PDF for Python.
1210 ❒ ISSN: 2502-4752 smart contracts directly dene the terms of agreements between parties. Nick Szabo introduced the concept of smar t contracts in the early 1990s [5], aiming to enable transactions and agreements without middlemen, thereby reduci ng costs and enhancing trans parenc y . By le v eraging the immutabili ty and decentra lization of blockchain, smart contracts pro vide a trusted and transparent w ay to fulll contractual oblig ations, allo wing the automatic e x ecution of agreed terms between untrusted parties. Despite their potential, smart contracts ha v e increasingly become tar gets for sophisticated c yber threats that can compromise the inte grity , a v ailability , and condentialit y of entire blockchain platforms. This vulner - ability arises from the inherent comple xity of smart contracts, their unique programming paradigm, and the immutable nature of blockchain transactions [6]. Exploit ing vulnerabilities in smart contract code can lead to une xpected outcomes, tarnishing the reputation and undermining trust in the blockchain platform. A notable instance of such an e xploit occurred in 2016 with the Decentralized Autonomous Or g anization (D A O), where attack ers took adv antage of a vulnerability in the D A O’ s contract, leading to the theft of 3.5 million Ethers, v alued at approximately 45 million USD at the time [7]. Researchers ha v e proposed v arious methodologies for detecting vulnerabilit ies in s mart contracts uti- lizing symbolic and dynamic analysis as well as machine learning techniques. One of the earliest tools de v el- oped for this purpose is O YENTE [8], which utilizes static symbolic e x ecution to re v eal vulnerabilities in smart contracts. O YENTE w as tested on 19,366 Ethereum smart contracts and successfully detected vulnerabilities in 8,833 of them, i ncluding the notorious D A O issue. This tool can identify vulnerabilities such as reentranc y , transaction ordering dependenc y , timestamp dependence, and mishandled e xceptions. Another tool, Mythril [9], utilizes symbolic e x ecution techniques to e v aluate potential vulnerabili ties in smart contracts. When it detects undesirable conditions, it v alidates or dismisses them based on specic assumptions. Similarly , Slither [10], designed to detect reentranc y vulnerabilities, utilizes static analysis tech- nique by con v ert ing the solidity abstract syntax tree (AST) into an internal representation language called SlithIR, which is then analyzed for vulnerabilities. Securify [11], a dynamic analysis tool, detects a ws in Ethereum smart contracts by e xtracting seman- tic information through symbolic e x ecution on the contract’ s dependenc y graph. It observ es compliance and violation patterns to v erify spec ic properties. Lik e wise, sFuzz [7] combines a lightweight, adapti v e strate gy with American fuzzy lop (AFL) fuzzing to detect up to nine types of smart contract vulnerabilities. Contract- Fuzzer [12] generates fuzzing inputs based on the smart contract’ s constructor ar guments and its application binary interf ace (ABI) to detect a range of vulnerabilities including g asless sends, block number dependenc y , reentranc y , e xception handling issues, frozen ether , and dele g ate call vulnerabilities. Additionally , a machine learning-based vulnerability detection model [13] using K-nearest neighbors (KNN) has been proposed, ef fecti v ely identifying vulnerabilities such as access control, arithmetic errors, bad randomness, denial of service, reentranc y , and uncheck ed lo w-le v el calls. Another approach [14], emplo ying heterogeneous graph transformers (HGTs) and node-le v el attention has sho wn s uccess in detecting vulnera- bilities at both coarse and ne-grained le v els. Furthermore, a model called the serial-parallel con v olutional bidirectional g ated recurrent netw ork [15] w as de v eloped t o preserv e the spatial and temporal structure of smart contracts while e xtracting features from the input sequence to detect vulnerabilities such as reentranc y , timestamp dependenc y , and innite loops. Despite the gro wing attention to smart contract security , research on vulnerability identication, anal- ysis, and mitig ation remains fragmented. Man y studies focus on isolated aspects of smart contract security , lea ving g aps in understanding ho w the dif ferent el ements interact. Additionally , there is a lack of comprehen- si v e domain-based classication and a structured approach to cate gorizing e v olving threats. This fragmented understanding hampers the ability of researchers, de v elopers, and polic ymak ers to ef fecti v ely communicate, analyze, and address the multif aceted security challenges in the blockchain ecosystem. This systematic re vie w addresses these g aps by thoroughly e xamining e xisting literature and cate- gorizing smart contract vulnerabilities into code-le v el, en vironment-dependent, and user -related domains. By or g anizing smart contract threats into coherent cate gories and analyzing the associated attack v ectors and de- tection methods, the re vie w of fers v aluable ins ights for researchers, de v elopers, and the broader blockchain community . It of fers a comprehensi v e frame w ork for understanding smart contract threats and stak eholder roles, enabling the de v elopment of ef fecti v e security strate gies, informing re gulations and standards that pro- mote secure de v elopment practices and promoting trust in blockchain technology . It also serv es as a foundation for further research into specic smart contract vulnerabilities and corresponding mitig ation strate gies. Indonesian J Elec Eng & Comp Sci, V ol. 37, No. 2, February 2025: 1209–1224 Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian J Elec Eng & Comp Sci ISSN: 2502-4752 ❒ 1211 2. METHOD This study utilized a systematic re vie w (SR) methodology to thoroughly e xamine the current thre at landscape of smart contracts. The re vie w w as conducted using the preferred reporting items for systematic re vie ws and meta-analysis (PRISMA) guidelines [16], ensuring a transparent and replicable process. These guidelines pro vide a structured frame w ork that helps maintain consistenc y , tra nsparenc y , and replicability in conducting and reporti ng systematic re vie ws. By adhering to PRISMA, we focused on planning, e x ecuting, and presenting systematic re vie ws with enhanced quality , reliability , and comparability . The systematic re vie w process in this study in v olv ed v e k e y stages: planning, searching, ltering, selection, and eligibility assess- ment. This approach is based on empirical data and theoretical analysis, which guarantees the quality and comprehensi v eness of the research. 2.1. Planning the r e view This systematic re vie w follo ws a structured methodology that thoroughly e v aluates the e xisting re- search on the topic. The process be gins by identifying the ne ed for the re vie w and formulating research ques- tions, which serv e as guiding criteria for selecting and assessing all reference articles i n c luded in t he re vie w . This study used four specic research questions to direct the systematic re vie w process. A detailed description of these questions is pro vided in T able 1. T able 1. Research questions and objecti v es Research questions Objecti v es RQ1: What are the most common code-le v el vulnerabilities found in smart contracts? T o identify the primary code-le v el vulnerabilities in smart contracts of fering a detailed analysis of their impact. RQ2: What en vironment-dependent vulnerabilities can impact the security of smart contracts? T o identify en vironment-dependent vulnerabilities in smart contracts and assess their impact. RQ3: What user -related vulnerabilities are link ed to smart contracts? T o e xplore user -related threats in smart contracts, emphasizing ho w user interactions and beha viors can contrib ute to security breaches. RQ4: What are the most ef fecti v e techniques for detecting vulnerabilities in smart contracts? T o e xamine and assess the ef fecti v eness of v arious techniques and approaches for detecting vulnerabilities in smart contracts, including their strengths and limitations. 2.2. Database and sear ch strategy W e thoroughly se arched se v eral electronic scholarly databases, including IEEE Xplore, Science Di- rect, MDPI, Springer Link, A CM Digital Library , and Google Scholar . Additionally , we re vie wed rele v ant journals in the eld, such as the Indonesian Journal of Electrical Engineering and Computer Science (IJEECS) and the International Journal of Computers and Applications (IJCA). The search used a range of k e yw ords, including “smart contracts, ” “vulnerabilities, ” “attacks, ” “blockchain, ” “security , ” “threats, ” “defense mecha- nisms, ” “detection, ” “mitig ation strate gies, ” and “b ugs, ” as detailed in Figure 1. The search focused e xclusi v ely on peer -re vie wed journal articles, conference proceedings, and book chapters published in English from Jan- uary 2016 to June 2024. This process yielded a total of 342 articles, with cont rib utions from IEEE Xplore (79), Science Direct (42), A CM Digital Library (67), Springer Link (31), MDPI (68), Google Scholar (50), IJEECS (3), and IJCA (2). Figure 1. Search strate gy terms 2.3. Inclusion and exclusion criteria W e implemented a set of inclusion (IC) and e xclusion ( EC) criteria, outlined in T able 2, to ensure the rele v ance and quality of the selected studies. Articles that did not meet these criteria were e xcluded from the analysis as illustrated in Figure 2. Navigating the smart contr act thr eat landscape: a systematic r e vie w (Unyime Ufok Ibekwe) Evaluation Warning : The document was created with Spire.PDF for Python.
1212 ❒ ISSN: 2502-4752 T able 2. Inclusion and e xclusion criteria Inclusion criteria Exclusion criteria Articles published from 2016 to 2024. Duplicate literature. Studies that satisfy at least one of the specied search criteria. Studies that are not rele v ant to the topic. Articles published in scholarly journals, conference proceedings, or academic periodicals. Non-peer -re vie wed articles, including blog posts and opinion pieces. Studies of fering empirical data or theoretical analysis. Research papers not written in English. Figure 2. PRISMA o w diagram 2.4. P aper selection The selection process in v olv ed three main stages: i) Remo ving duplicate articles and performing an initial screening of titles and abstracts to eliminate studies that did not meet the specied criteria and k e yw ords. ii) Conducting a full-te xt re vie w and thorough e xamination of the papers for nal selection. iii) Assessing the quality of the remaining papers and discard those that did not meet the inclusion criteria. The initial search produced 342 articles. After el iminating duplicates and re vie wing the titles and abstracts, 127 articles remained for further e v aluation. An additional 49 articles were e xcluded due to insuf cient information, res ulting in 78 articles for the systematic re vie w . 2.5. Eligibility The selection results sho wed that 264 articles did not meet the inclusion cr iteria, lea ving 78 arti cles for the systematic re vie w . These selected studies were thoroughly e xamined, and data were e xtracted using a standardized form to ensure consistenc y . The e xtracted data included: (i) bibliographic details (author , title, publication year , journal/conference), (ii) types of vulnerabilities identied, (iii) associated attack v ectors and e xploitation techniques, (i v) detection methods and e xperi mental setups, (v) proposed solutions and mitig ation strate gies, and (vi) k e y ndings. This data w as synthesized to create a comprehensi v e concept u a l frame w ork that cate gorizes smart contract vulnerabilities into three main domains: code vulnerabilities , e x ecution en vi- ronment threats, and user -related threats. Indonesian J Elec Eng & Comp Sci, V ol. 37, No. 2, February 2025: 1209–1224 Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian J Elec Eng & Comp Sci ISSN: 2502-4752 ❒ 1213 3. RESUL TS AND DISCUSSION This section consolidates the ndings from the systematic re vie w (SR) of 78 selected articles, pro- viding a detailed analysis to address the research questions. The SR identied k e y vulnerabili ties in smart contracts and their underlying causes, cate gorizing these vulnerabil ities and related attacks into three domains: code-le v el, en vironment-dependent, and user -related. Additionally , the re vie w e xamined the techniques used to detect these vulnerabilities. The proposed classication of vulnerabilities into code-le v el, en vironment-dependent, and user -related domains e xtends the e xisting smart contract weakness classica tion re gistry (SW C). While the SWC of fe rs a comprehensi v e taxonomy based on technical characteristics and root causes, our ne w classication scheme introduces a fresh perspecti v e, emphasizing the di v erse nature of the challenges and the v arious stak eholders in v olv ed, such as de v elopers, platform pro viders, and users. This ne w approach pro vides v aluable insights that can guide the de v elopment of tar geted mitig ation strate gies and best practices tailored to each vulnerability cat- e gory . It also aids in prioritizing and allocati ng resources more ef fecti v ely , focusing on the m ost critical types of vulnerabilities. This SR identied thirteen (13) of the most common smart contract vul nerabilities, which are discussed in detail as we address the research questions. T able 3 lists these prominent vulnerabilities, cate gorized into the three domains based on the selected papers. T able 3. T axonomy of smart contract vulnerabilities Domain V ulnerability type Kno wn attacks Code-le v el vulnerabilities Reentranc y [6], [8], [12], [15], [17]-[40] D A O attack [22], [37], [38] Inte ger o v ero w/undero w [5], [15], [17]-[19], [23], [31]-[34], [41]-[47] BEC contract attack [45], [46] Poolz nance hack [47] Mishandled e xception [8], [13], [17]-[18], [26], [31]-[32], [36], [40]-[41], [47] King of the ether throne attack [8] Freezing ether [12], [15], [18], [31], [48]-[50] 2017 P arity multisig w allet attack [12], [15], [49], [50] Uninitialized storage v ariables [6], [23] P arity multi-signature w allets [6] Inconsistent access control [40]-[41], [51]-[53] data leakage [52] Self-destruct [52] - Short address [13], [40], [51] - En vironment-dependent vulnerabilities T imestamp dependenc y [5], [8], [12],[15], [17], [19], [26], [28], [31]-[32],[38], [47], [54], [55] - External oracles dependenc y [29], [55], [56], [57] DeFi ’Flash Loan’ attack [55] User -related vulnerabilities tx.origin [25], [26], [31], [32], [36], [52] Social engineering and phishing attacks [26] T ransaction ordering [5], [8], [17], [18], [23], [29], [47], [49], [55], [58], [59] MEV crisis [55] Denial of service[13], [52], [60] King Of Ether Throne threat [60] 3.1. RQ1: What ar e the most common code-le v el vulnerabilities f ound in smart contracts? The literature re vie w on code-le v el vulnerabilities in smart contracts re v eals se v eral signicant issues resulting from programming errors, logical a ws, or improper use of language features. The re vie w identied reentranc y , inte ger o v ero w/undero w , and mishandled e xceptions as the most common code-le v el vulnerabil- ities. De v elopers can mitig ate these inherent vulnerabilities by embracing secure coding practices, performing thorough testing, and follo wing established security practices and guidelines. Implementing these strate gies enhances smart contracts’ security and reliability , reducing the lik elihood of successful attacks. 3.1.1. Reentrancy In this re vie w , studies [17]–[40] ha v e identied reentranc y vulnerabilities in smart contracts. These vulnerabilities arise when a malicious contract calls anot her contract that lacks suf cient security checks be- fore the initial e x ecution is nished. Similarly , researchers in [6], [8], [12], and [15] ha v e also in v estig ated reentranc y issues. Such vulnerabilities allo w attack ers to manipulate the contract’ s state. In these scenarios, the malicious contract may r epeatedly call the original contract, resulting in unintended modications to its state. By emplo ying a recursi v e callback within the main function, an attack er can create an innite loop to drain funds. A notable e xample of this vulnerability is the 2016 D A O attack [22], [37], [38], which led to the unauthorized withdra w al of o v er 50 million USD in Ether [19], [26], [39]. T o mitig ate this risk, it is advised Navigating the smart contr act thr eat landscape: a systematic r e vie w (Unyime Ufok Ibekwe) Evaluation Warning : The document was created with Spire.PDF for Python.
1214 ❒ ISSN: 2502-4752 to use ‘send()’ or ‘transfer()’ for transfer operations and to update the internal state before e x ecuting lo w-le v el calls [32], [40]. 3.1.2. Integer o v ero w/undero w In smart contract code, inte gers are usually dened as x ed-size or non-signed inte ger types [5] thereby restricting the range of v alues that inte ger v ariables can hold. Inte ger o v ero w occurs when an inte ger v ariable e xceeds its maximum allo w able v alue, causing it to wrap around and restart from the minimum v alue. Con v ersely , inte ger undero w happens when an inte ger v ariable f alls belo w its minimum allo w able v alue, lead- ing it to wrap around and assume the maximum v alue of the inte ger’ s data type [41]. These vulnerabilities can result in incorrect transfers, loss of funds, and other security issues. The re vie w identied from studies [5], [15], [17]-[19], [23], [31]-[34], [41]-[47] that arithmetic op- erations producing une xpected v alues due to e xceeding or f al ling belo w the dened inte ger range can lead to inte ger o v ero w/undero w vulnerabilities. A notable e xample is the Beauty Chain (BEC) contract attack [45], [46] in April 2018, where an attack er e xploited an inte ger o v ero w vulnerability to duplicate tok ens endlessly , leading to the instantaneous loss of o v er 900 million USD [17]. Additionally , Poolz Finance suf fered a signi- cant arithmetic o v ero w hack due to a a w in its pool creation method, in v olving manual summation of tok en counts, resulting in a 6,650,000 USD loss [47]. W ithout a mechani sm to detect inte ger o v ero w and under - o w , attack ers can potentially g ain more tok ens than the y are entitled to. T o address these risks, researchers recommend using safe math libraries or b uilt -in functions [31], [ 3 2] which are designed to detect and man- age o v ero w or undero w conditions and pro vide mechanisms to re v erse transactions if such conditions are detected. 3.1.3. Mishandled exceptions Studies [8], [13], [17], [18], [40], [41], [47] ha v e identied mishandled e xception vulnerabilities in smart contracts. These vulnerabilities occur when the contract f ails to properly handle e xceptions or errors during e x ecution or from e xternal function calls, potentially leading to unauthorized access to funds or other resources. Mishandled errors are also identied as uncheck ed calls in literature [26], [31], [32], [36]. Smart contracts can interact with one another through lo w-le v el functions such as dele g atecall, send and call [17], which do not automatically trigger e xceptions when errors occur . Instead, these functions return a boolean v alue indicating the success of the call. If the return v alues of these lo w-le v el calls are not adequately v eried, it can lead to ”f ail-open” scenarios and other unintended consequences [13], [41]. Contracts with functions lik e send, call, callcode, and dele g atecall are particularly vulnerable to uncheck ed lo w-le v el call issues [26]. Notable e xamples of attacks e x pl oiting mishandled e xception vulnerabilities include the P arity multi-signature w allet incident on Ethereum, which resulted in the loss of o v er 31,000,000 USD w orth of Ether [40], and the King Of The Ether Throne attack [8]. T o mitig ate these vulnerabilities, it is recommended to use higher -le v el functions lik e transfer and send, which automatically re v ert on f ailure, rather than lo w-le v el functions lik e call and dele g atecall. Additionally , contracts should v erify the return v alues of instructions to ensure proper e x ecution [17]. 3.1.4. Fr eezing Ether The freezing Ether vulnerability occurs when Ether becomes lock ed and i n a ccessible. Studies [12], [15], [18], [31], [49], [50] ha v e identied that this issue arises because smart contract de v elopers often f ail to properly account for the Ether transfer function when designing their contracts. The y frequently focus solely on the recei v e function, which allo ws the contract to accept ether deposits, without ensuring that the contract can also transfer it out. As a result, Ether recei v ed by the contract can become frozen and unusable. This issue is particularly problematic for contracts that depend on e xternal contracts (via dele g atecall) for Ether transfers. If these e xternal contracts perform a suicide or selfdestruct operation, the calling contract loses its ability to send Ether , leading to the freezing of all its Ether . A notable e xample of this vulnerability is the 2017 P arity multisig w allet incident, where the self-destruction of the P arity w allet library contract resulted in o v er 280 million USD w orth of Ether being frozen and inaccessible [12], [15], [49], [50]. This vulnerability is specic to Ethereum- based s mart contracts. T o mitig ate this risk, it is advised that contract s designed to recei v e Ether should include mechanisms for Ether withdra w al or transfer , using functions such as transfer , send, or call.v alue() operations [31]. Indonesian J Elec Eng & Comp Sci, V ol. 37, No. 2, February 2025: 1209–1224 Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian J Elec Eng & Comp Sci ISSN: 2502-4752 ❒ 1215 3.1.5. Uninitialized storage v ariables Studies [6], [23] ha v e highlighted that vulnerabilities related to uninitialized storage v ariables aris e when storage pointers are left uninitialized, resulting in unintended o v erwriting of storage v ariables. A notable e xample is the P arity multi-signature w allet attack [6] in July 2017, which e xploited a vulnerability associated with uninitialized function access control in the smart contract library used by P arity multi-signature w allets. This vulnerability allo wed attack ers to g ain control of the w allet and steal o v er USD 150 mill ion w orth of Ether . T o mitig ate such risks, it is essential to e xplicitly set def ault v alues for v ariables. This practice ensures that v ariables ha v e well-dened states before interacting with other v aria bles, thereby pre v enting une xpected beha viors. 3.1.6. Inconsistent access contr ol This issue often arises from t he o v ersight or ine xperience of contract de v elopers in creating and im ple- menting access control mechanisms [41]. Improperly congured visibility settings in smart contracts can gi v e attack ers easy direct access to a contract’ s pri v ate v alues or internal logic [51]. If sensiti v e data or critical func- tions are not appropriately mark ed as pri v ate or internal, the y become vulnerable to e xploitation by malicious actors. Attack ers might be able to directly interact with these e xposed elements, allo wing them to read pri v ate data or bypass intended access controls. This can lead to poor perm ission management, permitting malicious users to access or change sensiti v e information and functions. Such access control is sues pose signicant se- curity risks, including loss of funds, contract tampering, and data leakage [52]. T o pre v ent inconsistent access control vulnerabilities, de v elopers should clearly specify the visibility of all contract functions [40]. Use the ‘pri v ate’ k e yw ord for internal logic and data that should remain inaccessible outside the contract, ‘internal’ for functions and data that should only be accessible within the contract or its deri v ed contracts and implement access control modiers such as ‘onlyOwner’ or custom access control checks to restrict access to sensiti v e functions. 3.1.7. Self-destruct The self-destruct vulnerability in smart contracts occurs when a contract includes a function that al- lo ws it to be terminated. As noted by Liao et al. [52], if a contract has a selfdestruct function, an attack er who g ains control of the contract could call this function, leading to the contract’ s une xpected termination. Thi s can result in the loss of funds or disruption of the contract’ s intended operations. Often, contracts include critical logic or perform calculations based on their balance within the f allback function. Ho we v er , this logic can be bypassed using the self-destruct function, which lets a user specify a beneciary for an y remaining Ether . Con- sequently , a vulnerable contract can be e xploited to transfer all funds to the attack er’ s account while shutting do wn the contract’ s operations. 3.1.8. Short addr ess The short address vulnerability occurs when a contract recei v es fe wer bytes of data than e xpected. This issue arises because the Ethereum virtual machine (EVM) incorrectly a ccepts ar guments with insuf cient padding [51]. When this happens, the EVM automatically lls the missing bytes with zeros, starting from the highest byte of the subsequent parameter [13]. Since the deplo yed smart contract cannot pre v ent this automatic padding, it may interpret these zeros as v alid input data. This vulnerability results from the EVM’ s f ailure to v alidate address lengths. T o mitig ate this issue, smart contract de v elopers should implement checks within their contract code to v erify the length of transaction input data [40]. 3.2. RQ2: What en vir onment-dependent vulnerabilities can impact the security of smart contracts? Smart contracts as essential elements of blockchain-based systems, are inherently inuenced by the comple xities of the blockchain en vironment. Therefore, en vironment- d e pendent vulnerabilities stem from the interplay between smart contracts and the broader blockchain ecosystem and the distincti v e features of the underlying distrib uted ledger technology [53], [54]. Addressing these en vironment-dependent vulnerabilities requires a thorough understanding of blockchain architecture, smart contract inte gration, and the de v elopment of rob ust mechanisms to manage e xternal dependencies ef fecti v ely , thereby impro ving t he security and relia- bility of smart contract-based applications. 3.2.1. T imestamp dependency Se v eral studies [5], [8], [12], [15], [17], [19], [26], [28], [31], [32], [38], [47], [55] ha v e highlighted vulnerabilities related to smart contracts that depend on block timestamps for entrop y or for e x ecuting critical Navigating the smart contr act thr eat landscape: a systematic r e vie w (Unyime Ufok Ibekwe) Evaluation Warning : The document was created with Spire.PDF for Python.
1216 ❒ ISSN: 2502-4752 operations. These vulnerabilities arise when smart contracts use precise block timestamps to mak e signicant control o w decisions [5]. This dependence on timestamps renders contracts vulnerable to manipulation by attack ers. In a decentralized blockchain netw ork, miners can adjust block timestamps within a windo w of less than 900 seconds [28], [32], potentially e xploiting arbitrage opportunities or g aining unf air adv antages [38]. This issue also contrib uted to the miner e xtractable v alue (MEV) crisis [55]. T o address this vulnerability , it is advisable to use block numbers instead of timestamps, as block numbers are resistant to manipulation by malicious miners [31]. 3.2.2. Exter nal oracles dependency Research, including studies [29], [55]-[57] ha v e emphasized the risks associated with smart contracts relying on third-party data sources and oracles. Smart c on t racts frequently rely on oracles to supply essential e xternal data, such as pricing information, meteorological data, or mark et trends, to e x ecute blockchain trans- actions. Ho we v er , ensuring accurate, consistent, and reliable data is more comple x than it might seem. The design of the Oracle system and its inte gration with the smart contract can mak e it vulnerable to manipulation by adv ersar ies who can e xploit the data source for malicious purposes. A notable e xample of this vulnerability w as the 2020 DeFi ’Flash Loan’ att ack, which resulted in the irre v ersible loss of approximately USD 100 mil- lion due to s uch e xploits [55]. T o m itig ate this risk, researchers ha v e suggested using ti me-weighted a v erage prices when consulting price oracles on the Ethereum platform [29]. 3.3. RQ3: What user -r elated vulnerabilities ar e link ed to smart contracts? One cate gory of vulnerabilities in smart contracts arises from interactions between users and the con- tract itself. These user -related vulnerabilities often result from f actors such as limited security a w areness among users, insuf cient user authentication mechanisms, poor k e y management practices, and the e xploitation of hu- man error . In 2022, o v er 1.9 billion USD w as estimated to be lost due to breaches e xploiting weaknesses in smart contract logic and user errors [47]. T o address these vulnerabilities, a user -centric approach is essential including ef fecti v e user education, creating secure user interf aces, and implementing rob ust k e y management practices. 3.3.1. T ransaction ordering Studies [5], [8], [17], [18], [23], [29], [47], [49], [55], [58], [59] ha v e reported vulnerabilities related to transaction ordering, which depend on the sequence in which transactions are e x ecuted. In a blockchain netw ork, the order of transaction e x ecution is determined by miners [5]. Some contracts require transactions to follo w a specic sequence. When multiple transactions are submitted simultaneously , the miner decides their e x ecution order [49]. The user whose transaction is processed rst may recei v e a re w ard, so the miner’ s chosen transaction order inuences the nal state of the contract. Malicious miners could e xploit this by prioritizing their transactions or reordering the sequence [8], [17]. This issue contrib uted to the MEV crisis, where high g as fees paid by bots e xploiting these opportunities create substantial security risks at the consensus layer [55]. T o address this vulnerability , researchers suggest implementing a cryptographic commit-re v eal scheme [59]. This method in v olv es obfuscating sensiti v e information within the transactions, such as g as prices or transaction v alues. By concealing this information, it becomes more challenging for attack ers to manipulate transaction ordering and e xploit the vulnerability . 3.3.2. Denial of ser vice DoS attacks pose a signicant risk to the stability and reliability of smart contracts arising fr om v arious causes. In a DoS attack, the attack er aims to inundate the smart contract with e xcessi v e requests or computa- tionally demanding operations, ef fecti v ely blocking the contract from serving le gitimate users. This disruption can impair the normal functioning of the smart contract, potentially causing its f ailure [13]. F or e xample, an attack er might cause certain operations to f ail intentional ly to e x ecute a DoS attack [52]. If a function recur - si v ely transfers Ethers to a list of users and one of these transactions f ails, the entire operation may be re v erted. An attack er can e xploit this by deliberately causing the f ailure to e x ecute a denial-of-service attack. The King Of Ether Throne incident [60] illustrates such an e xploitation of this vulnerability . 3.3.3. tx.origin V ulnerabilities related to tx.origin ha v e been highlighted in studies [25], [26], [31], [32], [36], [52]. The tx.origin v ariable in smart contracts represents the address of the original transaction initiator and is some- times used to v erify the le gitimac y of a function caller for critical operations. Ho we v er , this method is prob- Indonesian J Elec Eng & Comp Sci, V ol. 37, No. 2, February 2025: 1209–1224 Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian J Elec Eng & Comp Sci ISSN: 2502-4752 ❒ 1217 lematic because tx.origin reects the original transaction c reator’ s address e v en if another smart contract calls the function. This can mislead the contract into belie ving the call comes from a le gitimate user , which may be from a malicious contract. Consequently , att ack ers can e xploit this a w to trick users into performing actions on compromised contracts [32], making them vulnerable to social engineering attacks [26]. F or e x- ample, adv ersaries can emplo y phishing techniques using a malicious intermediary contract to decei v e vic- tims into e x ecuting critical functions. T o address this vulnerability , ‘tx.origin’ should not be used for access control and authorization. Instead, use ‘msg.sender’ which accurately identies the immediate caller of the function [31], [36]. 3.4. RQ4: What ar e the most effecti v e techniques f or detecting vulnerabilities in smart contracts? The security of smart contracts has emer ged as a signicant concern for de v elopers and res earcher , prompting the in v estig ation of v arious techniques to identify and detect vulnerabiliti es within these systems. T o address RQ4, a comprehensi v e re vie w of empirical studies on smart contract vul n e rability detection w as performed, analyzing 78 se lected articles. The detection techniques identied were grouped as traditional methods, machine learning-based methods and h ybrid methods based on the technologies used. T able 4 outlines the dif ferent detection techniques discussed in the literature. 3.4.1. T raditional methods T raditional vulnerability detection techniques include static analysis, dynamic analysis, taint analysi s, fuzz testing, and formal v erication. Our re vie w identied se v eral static analysis tools used for detecting smart contract vulnerabilities such as Oyente [8], Silther [10], SmartCheck [31], V andal [36], MSmart [42], Madmax [44], MAIAN [61], Ethertrust [62], SmartScan [63], Ethainter [64], and A Check er [65]. Static symbolic e x ecu- tion tool identify potential b ugs without e x ecuting the code. The rst tool to use symbolic e x ecution for smart contract vulnerability detection is Oyente [8]. Other tools lik e Mythril [9], DefectCheck er [25], Manticore [66] and GasChe ck er [67] also utilize symbolic e x ecution to detect contract vulnerabilities. Symbolic e x ecution in- v olv es replacing program v ariables with symbols and performing symbolic computations during code tra v ersal, generating path conditions for each e x ecution path, which are crucial for v erifying path feasibility and detecting potential issues [68]. Osiris [6] combines symbolic e x ecution with taint analysis to identify inte ger b ugs, while Sereum [24] uses taint analysis to unco v er vulnerabilities. Fuzzing techniques are emplo yed by tools such as sFuzz [7], ContractFuzzer [12], ReGuard [37], CONFUZZIUS [69], and HFContractFuzzer [70]. These tools detect anomalies by inputting lar ge v olumes of randomly generated data into smart contracts and analyzing runtime beha viors to identify vulnerabilities. ContractFuzzer [12] w as the rst tool to apply fuz zing techniques to smart contracts, e xamining the ABI spec- ication to generate inputs and identify defects. The only formal v erication tool identied in our re vie w is Securify [11]. F ormal v erication uses logical models and rigorous mathemat ical reasoning to v erify the correctness and security of smart contracts [32]. 3.4.2. Machine lear ning-based methods Our SR e xamined v arious studies that emplo yed traditional machine learning and adv anced deep learn- ing techniques for detecting smart contract vulnerabilities. These methods ha v e demonstrated ef fecti v eness in analyzing lar ge datasets and unco v ering patterns that traditional techniques may o v erlook. Se v eral studies ha v e successfully applied machine learning and deep learning techniques to identify smart contract vulnerabilities such as reentranc y , timestamp dependenc y , inte ger o v ero w/undero w and transaction ordering. F or e xample, studies [13], [17], [27], [39], [71], [72] ha v e emplo yed machine learning a lgorithms to detect vulnerabilities. Specically , study [13] applied KNN to i dentify smart contract b ugs. In study [17], researchers utilized v e machine learning algorithms: eXtreme gradient boosting (XGBoost), KNN, random forest (RF), support v ector machine (SVM), and adapti v e boosting (AdaBoost) to detect smart contract vul- nerabilities. Study [27] de v eloped a RF classier to monitor blockchain transaction balances and metadata for vulnerability identication. Study [39] used a neural netw ork-based static analysis tool for detection of smart contract vulnerabilities. Study [71] utilized four machine learning classiers: RF , SVM, decision tree (DT), and neural netw ork (NN) to identify vulnerabilities in smart contracts, while study [72] emplo yed unsupervised learning algorithms such as K-means, agglomerati v e clustering, HDBSCAN, Spectral, and OneClass SVM to analyze transaction beha vior for vulnerability detection. Additionally , our re vie w highlighted v arious studies that focused on deep learning techniques. F or instance, study [4] introduced SmartEmbed for detecting con- tract code clones and b ugs, while study [26] de v eloped CodeNet , a CNN architecture for a w detection in Navigating the smart contr act thr eat landscape: a systematic r e vie w (Unyime Ufok Ibekwe) Evaluation Warning : The document was created with Spire.PDF for Python.
1218 ❒ ISSN: 2502-4752 smart contracts. Study [38] proposed the use of graph neural netw orks (GNN) for vulnerability identication, while study [49] presented ESCOR T , a deep neural netw ork frame w ork for detecting a ws in smart contracts. Furthermore, studies [73] and [74] introduced long short-term memory (LSTM) netw orks for transaction-based vulnerability classication and detection. Study [75] proposed the use of multiple-objecti v e detection neural netw ork (MODNN) for smart contract vulnerability detection. 3.4.3. Hybrid methods Our re vie w re v ealed that h ybrid methods, which inte grate traditional techniques with machine learning or combine multiple machine learning and deep learning approaches, are designed to le v erage the strengths of each method to enhance vulnerability detection. V arious studies ha v e implemented these h ybrid models for detecting vulnerabilities in smart contracts. F or instance , study [5] applied BiLSTM and other deep learning techniques for smart contract vulnerability detection, while study [14] incorporated multiple methods for smart contract vulnerability detection. Study [15] introduced the SPCBIG-EC for this purpose. Similarly , study [19] combined CNN with a self-attention mechanism. Study [28] e xplored the use of GNNs i n conjunction with e xpert kno wledge, and study [29] proposed GraphCodeBER T for smart contract b ug detect ion. Study [32] emplo yed a bidirectional g ated recurrent unit netw ork (Bi GR U) enhanced by an attention mechanism for smart contract vulnerabilit y detection. Study [41] also utilized BiLSTM and other deep learning techniques, while study [48] proposed a method that mer ges deep learning with multimodal decision fusion for detecting contract vulnerabilities. Further note w orth y approaches include study [51], which inte grated machine learning with fuzz testing, and study [76], which utilized a com bination of recurrent neural netw orks (RNN) and CNN for vulnerability detection. Study [77] introduced SCVDIE, a tool that emplo ys neural netw orks and ensemble learning to identify vulnerabilities in smart contracts. Additionally , study [78] mer ged Siamese netw orks with a deep learning model, and study [79] de v el- oped a tool using neural netw orks and slice matrices for detecting smart contract vulnerabilities. Finally , study [80] presented a h ybrid model that combines v arious w ord embeddings (W ord2V ec, F astT e xt) with deep learn- ing methods (LSTM, GR U, BiLSTM, CNN, BiGR U), while study [81] de v eloped a reentranc y vulnerability detection model using BiGR U and SVM. 3.5. Ev aluation of detection techniques Our systematic re vie w assessed t he strengths and limitations of v arious smart contract vul n e rability detection techniques. Although traditional methods can be ef fecti v e, the y ha v e notable dra wbacks. F or e xam- ple, symbolic e x ecution can achie v e high accurac y by generating control o w graphs (CFGs) from the tar get code [39]. Ho we v er , this process is computationally intensi v e and time-consumi ng as it in v olv es e xploring all possible states the code may transition through [17], [26], [49], [73]. Additionally , both s y m bolic e x ecution and fuzzing often incur signicant e x ecution o v erhead due to the need to run contracts symbolically . F ormal v erication methods f ace limitations due to the lack of specications for b uilt-in functions [22]. Static analysis techniques ha v e impro v ed in detecting vulnerabilities in smart contracts, yet the y often e xhibit relati v ely lo w accurac y rates [28]. Thes e methods generally rely on e xpert-dened patterns which can result in high f alse-positi v e and lo w f alse-ne g ati v e rates due to potential errors in pattern formulation [5], [32], [38]. As the number of smart contracts gro ws rapidly , it becomes increasingly impractical for e xperts to re vie w all contracts and create accurate patterns [28]. Machine l earning-based techniques ha v e o v ercome som e challenges of traditional methods by learning features directly from code, enabling v ersatile and ef cient analysis. Ho we v er , these methods mostly perform binary classication, cate gori zing contracts as either vulnerable or safe. The y often struggle to identify multiple types of vulnerabilities, which limit their adaptability [49] . While deep learning methods are ef cient and accurate with rapid detection rates [26], the y are constrained by their dependence on a single representation of code. This approach can o v erlook important semantic and syntactic features, as it often treats code as te xt sequences and ne glects critical v ariables in the data o w [28]. Additionally , this single-netw ork architecture may lead to incomplete e xtraction of vital information. Furthermore, deep learning models are often vie wed as ”black box es, ” which mak es their predictions harder to interpret [73]. Hybrid methods present signicant adv antages by combining the strengt h s of v arious techniques, leading to impro v ed performance in detecting smart contract vulnerabilities compared to the traditional or single deep learning models [15]. By inte grating mul tiple algorithms, h ybrid approaches ef fecti v ely address the weaknesses of indi vidual methods, resulting in more accurate and rob ust detection. Ho we v er , the y require considerable data, computational po wer , and resources for practical renement and optimization. Indonesian J Elec Eng & Comp Sci, V ol. 37, No. 2, February 2025: 1209–1224 Evaluation Warning : The document was created with Spire.PDF for Python.