## 1 Introduction
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Method Name** & **Description** & **Tools** \\ \hline Static analysis & Static analysis is the process of examining smart contract source code in order to identify possible risks and vulnerabilities. When the smart contract is not in use, this technique can be used to detect security. Code auditing can be carried out directly or automatically using tools like Smart Check [3] and Slither [4]. & Smart Check [3], Slither [4]. \\ Dynamic analysis & Dynamic analysis is the process of simulating contract’s implementation in an Ethernet virtual machine to find flaws and anomalies. When a smart contract has been deployed, this method is appropriate for security detection and can be carried out automatically using tools or manually. & ContractFuzzer [5] and Reguard [6] \\ Symbolic execution & Symbolic execution is the systematic testing of smart contract code using symbolic variables rather than concrete variables to identify various program execution paths and thereby finding possible flaws and anomalies. This method is appropriate for thorough security testing of smart contracts, but it also necessitates more computational time and resources. & Mythril [8] and Oyente [9] \\ Model testing & Model testing is the process of creating mathematical models of smart contracts and using model verification to identify possible flaws and anomalies. This technique is appropriate for thorough formal verification of smart contracts, but it necessitates a high level of computer science and mathematical knowledge. & SPIN [10; 11] \\ Model testing & As a method for demonstrating that a system meets certain properties, formal verification is based on logical and mathematical reasoning. It is one of the most precise ways to evaluate the system’s precision and early warning saving behavior. & Not fixed \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Detect smart contract vulnerabilities. Ethereum, combined with N-gram language to model static semantic tags, and predict potential vulnerabilities by identifying irregular tag sequences. In the literature [18], [PERSON] and [PERSON] introduced FSolidM for designing contracts as FSM. Software engineering tools provide standards for the development of smart contracts, thus standardizing the process of writing contracts. In the literature [19], [PERSON] proposed an attack categorization to focus on vulnerabilities in the code of smart contracts. They found that not all vulnerabilities were detected, providing a dangerous false sense of security that attackers can abuse. In the literature [20], [PERSON] proposed a fully automated vulnerability analyzer for smart contracts and using novel graph neural networks for vulnerability detection. A method for Mythril [8] internal model is proposed, because the Mythril [8] detection method is not accurate enough to detect vulnerabilities, producing false positives or missing positives; the Mythril [8] detection process is resource-intensive and time-consuming; some limitations exist for some advanced vulnerabilities, such as the inability to detect vulnerabilities that require specific scenario triggers or the inability to effectively detect advanced attack techniques. The system streamlines opcodes, reduces unnecessary opcodes, and increases detection efficiency to improve the accuracy and efficiency of smart contract vulnerability detection. The following steps make up the scheme's flow: The smart contract is the first written in Solidity and parsed, and its graph is built alongside the opcode in a step-by-step Python fashion. The graph has numerous branches, and the branches are generated using expressions like \"if\" and \"while\", after that, the analysis begins. The smart contract will automatically display the marker and use HTML to present the name, position, and cause of any vulnerabilities found in its path and nodes. If there is no vulnerability, it will examine the code until the end after displaying the information on the vulnerability.