# Vulnerability Detection and Classification of Ethereum Smart Contracts Using Deep Learning
## 2 Related Work
### Classification and Detection of Vulnerabilities in Smart Contracts  
Vulnerabilities in smart contracts can be classified and detected based on more than one input format such as source code, byte code, opcodes, and images. Moreover, previous studies have dealt with the use of some forms of smart contracts and the impact of using this form on the results of discovering vulnerabilities. However, few studies have taken it upon themselves to study the classification of vulnerabilities using deep learning [9; 34; 35]. In Ethereum, an opcode (operation code) refers to the fundamental operation that the Ethereum Virtual Machine (EVM) can execute [36]. Each opcode corresponds to a specific operation, such as arithmetic, stack manipulation, or control flow. However, the bytecode is the low-level representation of a smart contract composed of opcodes (a series of opcodes) and their operands [36]. [PERSON] et al. [35] introduced an automated framework for mining and classifying vulnerabilities in smart contracts. Utilizing a 4.4 KB primary dataset from CVE records and the NVD database, the framework addresses security vulnerabilities in two stages. Firstly, dynamic analysis techniques are employed to mine vulnerabilities in Ethereum smart contracts, monitoring their real-time behavior during execution. In the absence of execution, only the source code undergoes analysis. Subsequently, the mined vulnerabilities are classified based on Ethereum smart contract characteristics, impact, and patterns, ensuring a systematic approach. Notably, the framework goes beyond identification and classification, providing practical solutions to address and mitigate vulnerabilities within each identified category, reinforcing the robustness of smart contracts. [PERSON] et al. [37] proposed a method for categorizing smart contracts in decentralized applications (DApps) related to blockchain-based cyber-physical systems (CPS). Using characteristics taken from smart contract data, such as contract address, creation date, and invocation details, this method uses the same classification system as DApps. The process uses three feature kinds (value, code, and time) from 5659 DApps acquired using DappRadar, Ethereum, and the State of the DApps. These features are used to construct feature vectors, which are then fed into a DApp classification model that uses KNN,XGBoost, and random forests, based on an integrated taxonomy. Although several accuracy values were obtained, 0.886727 was the highest performance attained. [PERSON] et al. [38] utilized the ScrawID dataset, comprising 6780 labeled smart contracts, and incorporated a partially labeled dataset from smartBug. Unnecessary elements like comments and spaces were removed during dataset preprocessing, retaining crucial words in the smart contract source code. Two inputs were employed: the source code and Opcode (compiled source code instructions). The WEM process converted the source code to a matrix based on characters for neural network compatibility. FastText and BiGRU were employed for word embedding, representing each word as n-grams and extracting features. Serialization combined features into a layer, contributing to a classification accuracy of 79.7%. [PERSON] et al. [39] investigate the use of several Convolutional Neural Networks (CNNs) and a Long Short-Term Memory (LSTM) neural network in the application of deep learning to the classification of vulnerabilities in smart contract code. After considering five different vulnerability classes, the findings show that CNNs encourage accuracy, confirming the viability of the suggested approach. The study shows that vulnerabilities in smart contract programming may be efficiently found and categorized using deep learning techniques. After training and testing four neural network architectures, the 1D ResNet CNN produced the best results in terms of accuracy, 73.5%, and Micro F1 scores, 83.3%, when applied to smart contract bytecodes. The low performance of the LSTM baseline was probably caused by bytecode truncation.