# Hybrid Quantum-Classical Deep Neural Networks Based Smart Contract Vulnerability Detection
## 4 Experiment  
In this study, an HQCDNN classification model for smart contract vulnerability detection is used. The hardware and software tools we used in the study are a computer with Intel I9-13900K CPU, 24 cores, 64 GB main memory, 6 TB SSD, Proxmax operation system, Anaconda platform (open access), Python 3.12 programming language, Pandas 2.2.3 library, NumPy 2.2.4 library, Keras 2.14.0 library, Solcx 2.0.3 library, TensorFlow 2.14.0 library, Scikit-learn (Sklearn) 1.6.1 library, PennyLane 0.40.0 library, and MongoDB 8.0 database, respectively. Inthe proposed model, firstly, opcode data of smart contracts are extracted and feature vectors are created using the TF-IDF method. The SmartBugs Wild dataset initially consisted of 47,587 smart contracts. However, since the solcx library does not support Solidity versions 0.4.11 and earlier, contracts using those versions were excluded, reducing the database to 45,877 contracts. Thus, Solidity 0.4.11 and earlier make up approximately 3.5% of the entire dataset. In a 2017 announcement [73], the Solidity team addressed several security vulnerabilities found in earlier versions. Today, versions prior to 0.4.11 are no longer officially supported. Consequently, the analysis tools developed focus on Solidity 0.4.11 and later versions. Furthermore, [PERSON] et al. [3] used the same dataset and reported having filtered out contracts featuring what they refer to as \"premature\" compiler versions, ultimately experimenting on 24,957 contracts. This approach aligns with the aim of excluding outdated versions to more accurately represent the current smart contract ecosystem. In line with these considerations, our study also concentrates its analyses on Solidity \(\geq\) 0.4.11. Smart contract data are based on vulnerability types such as access control, arithmetic, front-running, reentrancy, time manipulation, denial of service, and unchecked low-level calls, which were flagged by dynamic and static analysis tools such as Mythril, Osiris, Oyente, Security, Slither, and SmartCheck. Table 2 presents only the vulnerabilities and tools for which more than 1000 instances were identified. For the model to be effectively trained, a dataset containing at least 1000 vulnerable smart contracts is required for each tool and vulnerability type. This threshold plays a crucial role in enabling the model to distinguish security vulnerabilities while enhancing its ability to learn different types of weaknesses and generalize effectively. There are 3665 smart contracts for which none of the analysis tools identified any vulnerabilities. These contracts are considered non-vulnerable and are included in the dataset as such to ensure balanced training for the models. There are instances where multiple tools have detected the same type of vulnerability in the same smart contract. In such cases, a vulnerability is considered for evaluation only if it has been marked by multiple tools at least 1000 times within the same contract. Table 3 presents the number of vulnerabilities commonly identified by multiple tools. For each tool, tool combination, and vulnerability type, a total of 25 different models were trained. To prevent data imbalance, the number of vulnerable and non-vulnerable instances was equalized. When constructing the training dataset, if the number of vulnerable contracts exceeded 3665, a random subset of 3665 vulnerable contracts was selected for inclusion. Conversely, if the number of vulnerable contracts was less than 3665, an equal number of non-vulnerable contracts was chosen to maintain data balance. This approach helps prevent learning errors caused by data imbalance during training, ensuring that the models produce more generalizable results.