An Opcode-Based Vulnerability Detection of Smart Contracts

Abstract

Aiming at the problem of insufficient technology for detecting smart contract vulnerabilities and the lack of improvement of certain detection tools, a method for the expansion and improvement of the internal module of the Mythril method is proposed. Since the technology of detecting vulnerabilities is not yet mature and there are vulnerabilities in smart contracts, vulnerability detection is particularly important. Since the Mythril tool covers the most types of vulnerabilities, its accuracy rate is also the highest. In order to ensure the effect of smart contract vulnerability detection, this paper proposes the expansion and improvement of the internal module of Mythril, which realizes the operation of automatic vulnerability analysis when performing vulnerability detection by improving the operation efficiency and simplifying the operation of smart contract opcodes while analyzing them. The comparison of experimental results shows that the proposed method is more suitable for smart contract vulnerability detection, and the detection accuracy and efficiency are improved, with an average accuracy rate of 94.07%. It performs better in vulnerability detection and provides an effective guarantee for the security and reliability of smart contracts, which has important application value and research significance.

1. Introduction

Smart contracts are classes of complete transaction protocols that computer scientist Nick Szabo created in 1994 [1] for autonomously carrying out, managing, or documenting events and behaviors connected to contracts. Smart contracts are blockchain-based protocols that enable blockchain to be completed securely and affordably without the need for centralized organizations. A significant issue in assessing whether blockchain can function regularly is the execution efficiency of smart contracts, which are globally distributed blockchain payment systems. The following traits apply to smart contracts: Smart contracts have the following features: (1) automatic execution, triggered by transactions without human intervention; (2) enforceability, once triggered, smart contracts cannot be stopped; (3) transparency, since smart contracts’ correctness must be verified by the majority of nodes in the blockchain; and (4) flexibility, allowing them to adjust to a variety of scenarios. Based on the nature of smart contracts, they present both numerous obstacles and many conveniences. The most popular smart contract development language at the moment is Solidity [2], but due to numerous security flaws in its contracts, including large fees and unverified external calls, it is important to introduce a more secure and practical development language for most programmers.

The security problems with smart contracts are caused by a variety of variables. (1) While open-source code can significantly lower the cost of intrusion, it can also increase user trust. Professional hacker groups will target any openly accessible smart contract. (2) For many programmers, the creation of programming languages and runtime environments for smart contracts, such as Solidity, is at a very early stage. Smart contracts will be vulnerable if coders are unable to address these issues. It is essential to carry out code analysis and discovery due to smart contracts’ numerous vulnerabilities and the possibility of financial losses. Before a project is deployed and during the development of smart contracts, various tools and techniques can be used to accurately identify protocol flaws quickly, preventing an attacker from learning about them and ensuring the security of blockchain transactions.

The following categories represent the primary methods for identifying smart contract vulnerabilities and are shown in

Table 1. Detect smart contract vulnerabilities.

Method Name	Description	Tools
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 [7]	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]
Formal verification [12]	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

:

In recent years, more and more research on methods for the detection of smart contract vulnerabilities has been carried out, and in the literature [13], Wei Wang propose ContractWard as a model to effectively and efficiently detect six types of vulnerabilities of smart contracts based on extracted static characteristics. In the literature [14], Amritraj Singh presented and analyzed the state-of-the-art research and achievements concerning the formalization approaches in smart contracts. In the literature [15], Hildenbrandt et al. designed an executable formal specification based on the Ethereum Virtual Machine bytecode stack language, KEVM, which is mainly aimed at modifying the Ethereum Virtual Machine environment, providing a safer environment for the development of smart contracts, making the formal analysis of smart contracts simpler, and they also use the official Ethereum test suite to verify the performance of KEVM. In the literature [16], Daejun et al. also propose a formal verification tool based on Ethereum bytecode, which has been applied to verify advanced smart contracts such as ERC20, Ethereum Casper, etc. In the literature [7], Zhou et al. designed a static analysis tool, SASC, based on the perspective of developing smart contracts to generate a syntactic topology diagram of the call relationship in smart contracts and mark the locations where risks and vulnerabilities may occur. In the literature [17], Liu et al. propose a semantic-aware security audit technology, S-gram Ethereum, combined with N-gram language to model static semantic tags, and predict potential vulnerabilities by identifying irregular tag sequences. In the literature [18], Mavridou and Laszka 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], Sarwar Sayeed 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], Zhung 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.

2. Materials and Methods

2.1. Blockchain

The blockchain [21] is the best defined as a shared, publicly accessible database that is updated by numerous machines. Blocks signify the sequential storage of data and information in “blocks”. To send ETH (ethereum) to someone, you must include the transaction information in a block [22]. Chaining refers to the practice of each block referencing its parent block cryptographically. To put it another way, blocks are connected. A block’s data cannot be modified without modifying all blocks which come after it, although doing so requires a network-wide agreement. Each new block and chain must be approved by all computers connected to the network. The word “node” refers to these computers. One has to make sure that the information is the same for everyone using the blockchain. A consensus mechanism is needed by the blockchain in order to implement this distributed protocol. Ether currently uses proof-of-work [23] (Pow) as the consensus algorithm, similar to Bitcoin. As a result, anyone attempting to add a new block to the chain must first crack a challenging logic puzzle that consumes a significant amount of processing power. You “prove” that you have used the arithmetic resources by resolving this puzzle.

2.2. Smart Contracts

The basis of Ethernet applications is smart contracts [1]. It is a computer application that can convert conventional contracts into equivalent electronic contracts and is kept on the blockchain. IFTTT’s logical framework and the logic of smart contracts are identical. This entails that they are unchangeable and exactly follow the program settings.

The phrase “smart contract” was the first used by Nick Szabo in 1994. In 1996, he wrote an examination of the functionality of smart contracts. A smart contract is Ethereum-based software. On the Ether blockchain, it is a collection of codes, datackchains, and datum. A contract account is a particular kind of Ethereum account that includes smart contracts. They are thus tradable through the network and have balance. They are programs on the network; they are not controlled but do exist. An individual user can communicate with a smart contract by sending a transaction to have a smart contract function executed. The same rules as in conventional contracts can be defined in smart contracts, and they can be implemented using code. A smart contract’s interaction with it is irrevocable by default, and it cannot be erased.

A 1-byte opcode is used in the EVM (Ethernet Virtual Machine) [24] to implement the opcode of a smart contract for the purpose of interpreting the smart contract. A low-level code, also known as an opcode, is created when Solidity is compiled by the Solc compiler. This code corresponds to the execution timing bytecode. The analysis process can be more adaptable if the sequence of opcodes is used as analysis data since smart contracts are typically distributed as source code but are stored as bytecode on the Ethernet main net.

2.3. Mythril Method

The Mythril [8] approach combines static analysis and symbolic execution. It is capable of detecting 14 additional vulnerability detection tools in addition to numerous smart contract security flaws like timestamp dependency, arbitrary address writing, and integer overflow. It can detect common vulnerabilities but not complex business logic problems. It makes use of the symbolic execution technique, which enables thorough code-level testing of smart contracts to identify a variety of potential flaws and anomalies. Additionally, Mythril analyzes smart contract source code using static split analysis techniques to find any potential security flaws. Because of this, Mythril has both the thoroughness and efficiency of symbolic execution as well as the capacity to swiftly scan and find code using static analysis techniques. The accuracy and effectiveness of Mythril’s vulnerability detection can be significantly increased with this combined strategy, making it a key instrument in the field of smart contract security detection. Using the Mythril Python module or directly through the API, programmers can publish command-line utilities. The drawback of Mythril is that it executes too slowly.

How it functions: Mythril executes smart contract bytecode in a specifically designed Ethereum virtual machine to verify the security of contracts. To check the potential state of the program, symbolic execution techniques are used, and the following stages are taken during the analysis process:

• Get the contract’s bytecode;
• Establish the contract account’s initial state;
• Using ‘n’ transactions, investigate the contract’s state space. Although it can be changed, n’s default value;
• When an undesirable situation is discovered, demonstrate or refute the assumptions that led to it. The transactions needed to obtain to a faulty state can be estimated after one is discovered. This can be used to exploit vulnerabilities in addition to aiding in the problem’s underlying cause identification.

3. Types of Vulnerabilities

3.1. Reentrant Vulnerabilities

Reentrant vulnerability is a frequent vulnerability; for instance, it was the reason the 2016 DAO [25] breaches smart contract was compromised. When a malicious contract that the attacker has control over is the target of an external call, the attacker may use malicious logic in the attacked contract to call the malicious contract before returning to the attacked contract, which will affect the attacked contract’s ability to function normally.

If smart contract A calls smart contract B on the Ethernet, then A’s current contract will pause until the call is finished. In this situation, the invoked contract B might leverage the contracted A in a connecting state to carry out nefarious deeds.

A smart contract’s reentrant vulnerability is described as follows: “Any transactions from A to B and any Ether conversions from A to B relinquish control to B, allowing B to call the code in A before the interaction is over. The malicious code in the “fallback()” method of the attacker’s contract D is activated if contract C transfers money to D. At that moment, D can finish the transaction by calling back to contract C. Contract C will sustain substantial financial losses if the fallback() function is repeatedly called before the initial call transfer procedure is finished.

3.2. Integer Overflow Vulnerabilities

There are three basic types of integer overflow in smart contracts: multiplication overflow, addition overflow, and subtraction overflow. Integer overflow is typically separated into upper overflow and lower overflow. An integer is typically defined in Ethernet smart contracts as fixed, unsigned integer type, meaning that it only reflects the value of an integer variable up to a specific range, which an integer overflow fault will occur. The step size of integer variables in the Solidity language is typically increased by eight before and after their inspection, and it supports uint8 to uint256. On the other hand, programmers can use the SafeMath complete library to handle the arithmetic logic, preventing integer overflow.

3.3. Short Address Vulnerabilities

The ABI paradigm is used to encrypt parameters before transmitting them into a smart contract. An encoded parameter that is shorter than the specified parameter length may be transmitted through a third-party contract (for example when transmitting 38 hexadecimal characters, or 19 bytes, instead of the standard 20-byte address). In this situation, the EVM adds a zero to the end of the code parameter to make up for the intended length. If the input in this situation is not vetted, then there will be an issue. The most prevalent instance is when a consumer requests an extraction and the exchange fails to validate the ERC20-tagged address.

3.4. Timestamp Dependency Vulnerabilities

Timestamp dependency describes the way that, as a smart contract is being executed, the consequence of the contract’s execution varies based on the timestamp. The timestamp contained in the smart contract is only accessible to a particular node (miner). Because one of the nodes (miners) is running its code locally, the timestamp acquired in the contract depends on that node’s computer local time. The local time can theoretically be changed by miners. Consequently, using block timestamps improperly in a smart contract might be very risky.

3.5. Transaction Sequence Dependency Vulnerabilities

Before a transaction can be loaded into a block, the miner must verify it. The miner will favorably choose the high-cost transaction for loading, and in some situations, the unpredictability of the sequence of transactions results in a certain risk. As a result, the attacker can advance the transaction by increasing the fee once they have the victim’s specific transaction information.

4. Smart Contract Vulnerability Detection Tools

Scholars and developers are currently paying increasing attention to the security issue surrounding smart contracts, and numerous techniques have been employed to thoroughly examine the Ether smart contracts and EVM bytecodes in order to prevent being exploited by malevolent attackers. Presently, symbolic execution, formal verification, static analysis, dynamic analysis, and model detection are the five types of detection methods suggested for the vulnerability detection approaches of smart contracts.

4.1. Symbolic Execution

A program analysis approach called symbolic execution [7] examines a program to determine how to allow a certain code area to run. As the name suggests, symbolic values rather than the precise values used in routine program execution are used as input when studying a program using symbolic execution. The analyzer may obtain the corresponding path constraints once the target code has been reached, and it can then utilize the constraint solver to determine the precise values that can activate the target code. The symbolic execution approach is appropriate for smart contract analysis because of the conciseness of smart contracts and the completeness of symbolic execution.

Oyente [9] analyzes a contract’s bytecode using the global Ether market and the contract’s bytecode as inputs, identifies any security flaws, and provides the user with the problematic symbolic routes. The Z3 solver [26] is employed in this procedure to ascertain satisfiability. With more precise estimation of the contract’s worst-case gas consumption (exchange fees), Oyente intends to assist developers in writing better contracts.

The first source code to LLVM’s [27] bitcode converter was created by Zeus [28], and on top of that, abstract interpretation and symbolic model checking are carried out for quick security testing.

The symbolic execution of Linux ELF binaries and EVM bytecodes is supported by the vulnerability analysis tool Manticore [29]. The system has the capacity to store and handle symbolic data, including timestamps, using its own EVM implementation. This system may be used to create an automatically produced test input and supports sending a sequence of symbolic transactions to the contract being tested. The test contract is examined for potential vulnerabilities using a set of detectors resembling those found in the Mythril analysis module. These detectors have the ability to use their own memory and respond to a sequence of callbacks at different execution points, such as when starting a new transaction or instruction. The detectors have the ability to capture the location and restrictions of potential vulnerability exploits in the code, which can be included in the test input output. Similar to Mythril, developers can use it as a Python third-party library or directly contact the API.

A symbolic execution tool based on bytecode parsing is called DefectChecker [30]. Control flow graphs, stack events, and three features are used to create eight distinct protocols for detecting vulnerabilities. Based on the severity of contractual vulnerabilities in prior studies, despite the fact that the symbolic execution technique can produce execution paths with greater accuracy, it also has a number of drawbacks, including the state space’s dramatic increase and the challenge of solving constraints that are incredibly complicated. These issues are frequently challenging to resolve.

4.2. Formal Verification

One of the most accurate techniques for evaluating a system’s accuracy and for verifying intelligent saving behavior in its early stages is formal verification [31]. Using mathematical language to fully define the desired behavior of the system to help increase correctness, formal verification works by first providing a system specification and then determining whether each step of the implementation complies with the specification. The steps below are typically included in the formal verification process to find smart contract vulnerabilities:

• Modeling: Turn the smart contract into a formal model by transforming the contract code into a form of a formal specification language (e.g., Solidity);
• Property specification: Specify the security characteristics that must be examined, such as that assets cannot be tampered with or that they are immune to reentrant assaults. Predicate logic or temporal logic are two examples of formal logic that can be used to define these property designations;
• Formal verification: Check the smart contract using formal verification techniques. Typically, this entails verification using instruments like model detectors and automated theorem provers;
• Analytical feedback: Examine the validation results, if flaws are discovered, inform the developer so that they may be corrected.

A mathematical justification for the system’s lack of certain vulnerabilities is provided through formal verification. This method’s advantage is its capacity to demonstrate the system’s completeness without omitting any weaknesses, to identify prospective issues. However, formal verification has several drawbacks, like being more challenging to execute, requiring specialized expertise and experience, and having some restrictions, such as being unable to address all types of vulnerabilities. As a result, formal verification is frequently seen as a cutting-edge method for systems with stringent security needs.

Solidity compilers, according to Bhargavan [32] are unreliable and might carry out attacks on bytecode rather than Solidity code. As a result, smart contracts’ source code and bytecode are both converted into the F* language [33] (a functional language for the purpose of program review).

4.3. Static Analysis

Software vulnerabilities can be found using a technique called static analysis, which examines the code directly. Static analysis is a tool that may be used to find vulnerabilities in smart contracts. The following steps are typically involved in the static analysis procedure used to find vulnerabilities in smart contracts:

• Code scan: To find potential flaws, static analysis tools scan smart contract codes. Lexical, syntactic, and semantic analysis of the code is often required for this;
• Detection of defects: After the scan is finished, the static analysis tool searches the code for errors such as integer overflows, array overruns, reentrant attacks, etc.;
• Vulnerability classification: The vulnerabilities are categorized so that programmers may find and address the issue right away.

Analysis feedback: Static analysis tools offer developers analysis feedback, which may include potential flaws, proposed fixes, and potential repercussions.

Static analysis can be automated to find vulnerabilities, which increases detection efficiency and accuracy when compared to manual code inspection. Static analysis techniques can increase the thoroughness of detection by looking through all potential code pathways to find undetected flaws. Static analysis does, however, have significant drawbacks, such as the potential to disclose some vulnerabilities incorrectly or to miss some vulnerabilities. Static analysis is therefore typically used in conjunction with other detection techniques to produce improved vulnerability detection findings.

Slither [4] is a static analysis framework that uses a variety of well-known program analysis techniques, such as data flow and contaminant tracing, to further refine information. Solidity smart contracts are named as SlithIR’s intermediate expressions. Slither has four key use cases: assisting with code audits, enhancing user comprehensions, discovering code optimization automatically, and finding vulnerabilities automatically.

4.4. Dynamic Analysis

By running smart contracts and watching their behavior, dynamic analysis uses smart contracts to find vulnerabilities. It differs from the static analysis approach, which examines the code without executing the contract, and the dynamic analysis method, which tracks the contract’s behavior as it is being executed.

The primary steps for applying dynamic analysis to find smart contract vulnerabilities as follows:

(a)

Creating test cases.

The dynamic analysis technique necessitates testing the smart contract, so it is necessary to create a set of test cases that cover as many scenarios as feasible. Examples of test cases include boundary cases, anomalous inputs, and normal inputs.

(b)

Run the test cases.

Run the test cases and keep an eye on how the smart contract behaves, either locally or on the test network. You can check the smart contract for state changes, function calls, transactions, and exceptions, while it is being executed using tools or manual techniques.

(c)

Examine the test outcomes.

Examine the test findings to look for any weaknesses. If vulnerabilities are discovered, they must be examined and patched, and the test cases must be run again to verify the effectiveness of the fix.

A dynamic analysis-based security vulnerability analysis method called Contract Fuzzer [5] is used to detect security flaws in Ethernet smart contracts by creating ambiguous test cases, which are based on the smart contract ABI specification. Contract Fuzzer configures the EVM, and its behavior was recorded as the smart contract was being executed. By analyzing the logs, vulnerabilities are found.

Reguard [6] is a fuzzy test analyzer for smart contracts that dynamically detects reentrant vulnerabilities by fuzzing smart contracts by iteratively generating random and multiple test cases to follow the contract throughout execution.

4.5. Model Detection Method

Model detection is a method for finding weaknesses in smart contracts that is based on formal specification descriptions and automated verification. By creating a model and iterating through its state space, the model detection approach finds all potential states and the transfer linkages between them. It can then check the characteristics of these states to see if any vulnerabilities are present. The model detection method’s primary steps for finding smart contract vulnerabilities are as follows:

(a)

Build the model

The smart contract can be formally tested by utilizing a model detection tool after being converted into a finite state machine model. A finite state machine or a Kripke structure, an extension of a finite state machine, can be used to describe the behavior of concurrent and distributed systems, which is typically used to build the model. A finite state machine is a mathematical model that describes finite states and transfers between states.

(b)

Establishing the characteristics

The properties that need to be validated must be identified after the model has been constructed. To represent the correctness and security of a smart contract, attributes are frequently utilized. They include security, correctness, and reachability. For illustration, security characteristics could include preventing double payments, preventing overflow protection, denial-of-service attack protection, etc.

(c)

Validate the attributes using model testing tools

The model detection tool is used to validate the constructed model and attribute. The model detection tool will automatically cycle through all the conceivable states, transfer relationships between states, and determine whether any states or paths match the requirements. A vulnerability exists and needs further investigation and correction if a state or path that satisfies the attribute is discovered.

SaferSC [34] is a smart contract vulnerability detection model that utilizes deep learning techniques to achieve better accuracy in detecting three different types of contract vulnerabilities. This model is based on Maian and goes beyond it by analyzing the operation code level of smart contracts in detail. The SaferSC model constructs a sequential model of the operation code of Ethereum using LSTM network (Long Short Term Memory). This allows the model to perform accurate and intelligent detection of security vulnerabilities of smart contracts. LSTM network is a type of recurrent neural network (RNN) that is particularly effective at processing sequential data, such as natural language or time series data. By using deep learning techniques, SaferSC is able to improve the accuracy of smart contract vulnerability detection compared to traditional methods. This can help prevent security breaches and protect users’ assets in the blockchain ecosystem.

DR-GCN is a contract graph-based approach for discovering vulnerabilities in smart contracts. This method transforms the source code of a smart contract into a highly semantically expressed contract graph and then constructs a security vulnerability detection model using a graph convolutional neural network. The model is capable of detecting vulnerabilities such as reentrancy, timestamp dependency, and dead loops in two platforms, Ether and Vitelink.

Although there are many automatic smart contract vulnerability verification tools available, most of them have certain shortcomings. First, their testing methods are simple and can only cover a limited range of vulnerabilities. Second, the code coverage is often low, resulting in a high rate of missing and false positives in the test results. Third, it is difficult to achieve fully automated detection and clear detection. Fourth, the usual detection time is long, and the mining speed of vulnerabilities is slow, leaving room for improvement in terms of expanding vulnerability coverage and improving detection efficiency. Therefore, there is a need for further research and development to address these shortcomings and improve the efficiency and accuracy of automatic smart contract vulnerability detection tools. This will help to ensure the security and reliability of smart contract systems in the blockchain ecosystem.

5. Detection of Smart Contract Vulnerabilities Based on Opcodes

The general framework of smart contract vulnerability detection using opcode analysis is shown in Figure 1. The framework first uses the Solidity language to write smart contracts and parse them. Then, it generates a chart while generating the opcode, which is conducted step-by-step using the Python language. The chart consists of multiple branches based on statements such as If or While. If there is a vulnerability detected, the framework will automatically display a marker and use HTML language to present information such as the name, location, and cause of the vulnerability. After showing the information of the vulnerability, the code will continue to run. If there is no vulnerability, the code will be analyzed until the end.

This framework utilizes opcode analysis to detect vulnerabilities in smart contracts, providing a clear and concise method for identifying security issues. By automatically displaying markers and presenting detailed information about the vulnerabilities, the framework makes it easier for developers to identify and fix security issues in their smart contracts. Overall, this framework can play an important role in improving the security and reliability of smart contracts in the blockchain ecosystem.

Analyzing the Smart Contract Opcode Flowchart

The approach of analyzing smart contract opcodes is an effective way to detect vulnerabilities in smart contracts, especially for those that are not open source. To perform opcode analysis, a control flow diagram is constructed using a directed graph consisting of base blocks and edges connecting the base blocks.

A base block contains only sequentially executed instructions, with only one input and one output. In the event of an unconditional jump command (JUMP), the current base block is terminated, and a new base block is formed with the JUMPDEST instruction as the first instruction of the new base block. In the event of a conditional jump command (JUMPI), the current base block is also terminated and split into two new base blocks. One of the new base blocks still uses the JUMPDEST command, while the other takes the command immediately following the conditional jump command as the first command.

By analyzing the control flow diagram and opcode, the smart contract vulnerabilities can be detected automatically. This approach is more efficient than analyzing the source code directly, especially for large contracts with complex logic. Improving the Mythril approach, the opcode analysis method provides a more effective and efficient way to detect vulnerabilities in smart contracts.

The following figure shows the improved Ponzi scheme smart contract as an example for comparison. Analyze the accuracy, efficiency, and streamlining of the Mythril method before and after the improvement.

The analysis of the Rubixi scheme smart contract opcode using the improved Mythril method is shown in Figure 2 and presented in flowchart form using HTML language. Each instruction in the basic block represents a state of the program (GlobalState), consisting of world state, machine state, and execution environment, and each field is represented by a symbolic value and a concrete value and also gives constraints on the path to be satisfied to reach the next basic block from one basic block. All opcodes have corresponding hexadecimal values, for example, the opcode 0 PUSH1 0 × 80 in the first block diagram copies the 1-byte value 0 × 80 to the ninth stack item, the hexadecimal value of “PUSH 1” is exactly “0 × 60”. By removing the non-mandatory “0×”, the logic can be written in byte code form as “6080”, but note that 0 × 40.0 × 80 cannot be interpreted as real numbers 40 or 80. So 40 is actually equal to 64 in decimal (16 × 4) and 80 is equal to (16 × 8) in decimal. In short what “PUSH1 0 × 80 PUSH1 0 × 40 MSTORE” is doing is allocating 128 bytes of memory and moving the pointer to the beginning of the 64th byte. In the EVM virtual machine, there are three places where data can be stored. First, in the stack, where the “PUSH” opcode was just used to store the data as in the example above. Second, in the memory (RAM) where the “MSTORE” opcode is used. And finally, in the disk storage, where the data is stored using the “SSTORE” opcode. Storing data in disk storage requires the most expensive gas, while storing data in stacked gas is the cheapest.

Smart contract vulnerability detection can be achieved by using Mythril to analyze opcodes and specifically analyze the type of vulnerability and its location. Although analyzing smart contract source code into opcodes is somewhat tedious and requires fetching stack information step by step, it is more intuitive to see which part of the process is faulty by the automatically generated flowchart. When the Rubixi scheme smart contract is analyzed using the pre- and post-improvement Mythril methods separately, it can be concluded that the improved Mythril runs at a faster rate.

Comparing Figure 2 with Figure 3, it can be clearly seen that the use of the improved Mythril method streamlines the contract opcodes and removes some useless opcodes, making the results seen clearer and reducing the scope of the block diagram.

In order to further verify whether the improved Mythril method is more accurate and efficient for detecting smart contracts, the same contract will be analyzed for comparison through experiments. Analysis of Ponzi scheme smart contract vulnerabilities using the improved Mythril method: Based on the code, it can be concluded that this contract has two vulnerabilities.

As can be seen from Figure 4, using the Mythril method before the improvement, the information of the vulnerability is not detected. And since there are virtual assets inside the smart contract, failure to detect the vulnerability in time will bring great loss.

Using the improved Mythril method to analyze the Ponzi scheme smart contract vulnerability, the details in Figure 5 are as follows:

SWC ID: 110 is the classification number of the vulnerability.

Severity: Medium: indicates the severity of the vulnerability.

Contract: Rubixi: indicates the name of the detected contract.

Function name: The name of the function where the vulnerability was found.

PC address: 1727: indicates the address of the program counter, short for Program Counter.

Estimated Gas Usage: 1830–1925: indicates the cost of the estimated gas overhead.

Vulnerability Description: Triggers assert assertion. Note that the solidity assert() statement should only be used to check for invariants, to see why a problem was generated, or to ensure that your program logic is correct. If your goal is to constrain user input or enforce prerequisites, use require() instead of assert(). Remember to validate the input from the caller (e.g., via passed parameters) and the callee (e.g., via the return value). What is shown afterwards is the model of the exploit code in the contract code, the code segment, and the initial state of the contract and the transaction sequence.

The above is the analysis of Ponzi scheme smart contract vulnerability using the improved Mythril method, you can clearly see that the smart contract vulnerability has an error in the name, number, and the first few lines, which is more convenient and efficient to improve the smart contract and can better protect the privacy and security issues.

Figure 5. Mythril analysis of Ponzi Scheme smart contract Vulnerability 1. (a,b) is the use of the improved Mythril method to analyze the Ponzi scheme smart contract vulnerability, it can be clearly seen that the name, number, and lines of the smart contract vulnerability have errors, which improves the smart contract more conveniently and efficiently, and can better protect privacy and security issues.

Figure 5. Mythril analysis of Ponzi Scheme smart contract Vulnerability 1. (a,b) is the use of the improved Mythril method to analyze the Ponzi scheme smart contract vulnerability, it can be clearly seen that the name, number, and lines of the smart contract vulnerability have errors, which improves the smart contract more conveniently and efficiently, and can better protect privacy and security issues.

6. Analysis of Experimental Results

6.1. Test Environment

For the detection of vulnerabilities part, the paper uses a PC as the experimental environment, deploys a virtual environment on the PC, uses Python for coding, and installs related library files such as Ethernet. The specific OS-level software configurations are shown in

Table 2. Specific OS-level software configurations.

Name	Version
Processor	12th Gen Intel(R) Core(TM) i9-12900H 2.50 GHz
Memory	RAM 16G
Virtual Machine	CentOS 7
Python	3.9.0
Solc	0.6.10
Z3-solver	4.8.9
Pysha3	1.0.2

.

6.2. Detection Performance Comparison

In order to obtain the data required for the experiment, a crawler script was written to obtain 2000 latest smart contracts and their operation codes from the official website of etherscan.io, including 400 game contracts, 400 social contracts, 400 financial contracts, 400 Gambling contracts, and 400 other contracts that guarantee the richness and randomness of the data. The pre-improved Mythril method and the improved Mythril method were used to conduct experiments on smart contract vulnerabilities, and the artificial statistical results are: Among the 2000 contracts, 236 test contracts have loopholes, and the true detection rate and false alarm rate of the two detection tools are determined, the statistical comparison chart is shown in Figure 6a,b. It can be seen from the figure that among the 2000 contracts, the method before the improvement detected 203 loopholes and 43 false positives; the improved method detected 222 loopholes and 20 false positives, so the false positive rates before and after the improvement are 21% and 9%, respectively. From the experimental results, it can be seen that the accuracy and false positive rate of the improved method have improved.

The performance evaluation of smart contract vulnerability detection tools mainly includes the following two aspects.

(a)

Accuracy: In order to evaluate the pros and cons of detection tools, we first focus on the most common evaluation index, namely accuracy. Accuracy can objectively reflect the most direct detection effect of various detection tools. Usually, the real situation is compared with the matching results of the detection results are used as an important evaluation index, including the following four situations.

• True positive (true positive, TP): For a certain contract, the detection result of the detection tool has loopholes, and the real situation also has loopholes, that is, the detection result is correct;
• False positive (false positive, FP): For a certain contract, the detection result of the detection tool is that there is a loophole, but the real situation is no loophole, that is, there is a misjudgment in the detection result;
• False negative (FN): For a certain contract, the detection result of the detection tool is that there are no loopholes, but the real situation is that there are loopholes, that is, there are missed judgments in the detection results;
• True negative (true negative, TN): For a certain contract, the detection result of the detection tool is no loopholes, and the real situation is also without loopholes, that is, the detection result is correct.

Obviously, the result of TP + FP + FN + TN is 2000 smart contract test samples, and the calculation method of the accuracy rate is shown in Formula (1):

$$\mathrm{acurracy}=\frac{\mathrm{TP}+\mathrm{TN}}{\mathrm{TP}+\mathrm{TN}+\mathrm{FP}+\mathrm{FN}}$$

(1)

(b)

F1-Score: F1-Score is an important measurement index in classification problems. It is the harmonic mean of precision and recall. It is often used as the final evaluation standard for some classification problems. Its calculation method is shown in Formulas (2)–(4):

$$\mathrm{Precision}=\frac{\mathrm{TP}}{\mathrm{TP} + \mathrm{FP}}$$

(2)

$$\mathrm{Recall}=\frac{\mathrm{TP}}{\mathrm{TP} + \mathrm{FN}}$$

(3)

$$\mathrm{F}1-\mathrm{Score}=2\times \frac{\mathrm{Precision} \times \mathrm{Recall}}{\mathrm{Precision} + \mathrm{Recall}}$$

(4)

The model proposed in previous studies was selected to compare the accuracy of detection and F1-Score under the same conditions. Comparison B. Muller’s Mytrhil [8], Luu’s Oyente [9], Smart Dec’s Smart Check [3], and Feist J’s Slither [4] use formulas to calculate the accuracy of each method as shown in

Table 3. Compare the results with previous methods of the research community.

Detection Tool	Total Number of Vulnerabilities	TP	FP	FN	Accuracy	$F1-\mathrm{Score}$
Mythril	236	203	20	23	86.02%	90.42%
Text scheme	236	222	16	4	94.07%	95.69%
Oyente	236	198	26	12	83.90%	91.24%
Slither	236	200	23	18	84.75%	90.70%
Smart Check	236	196	28	14	83.05%	90.34%

:

As shown in Table 3, the table shows the vulnerability detection results of the scheme, Mythril method, Oyente method, Smart Check method and Slither method are proposed in this paper. The experimental results show that the improved Mythril method in this paper has a better effect on detecting smart contract vulnerabilities and a higher accuracy rate. The average accuracy rate has increased from 84.5% before improvement to 94.07% after improvement. Compared with Oyente, another detection method of the symbolic execution method, the effect is significant.

6.3. Time Performance Comparison

In addition to the detection performance, the time performance of the system is also a very important measure. Therefore, the detection time performance of the Mythril method and Oyente before and after the improvement were compared through experiments.

The experimental data is still 2000 smart contracts, and these data are used to simulate the real detection environment of users using the three tools. In the experiment, three tools were used to test the test contracts one by one, and the detection time was recorded. Finally, the time performance comparison chart in Figure 7 was obtained. It can be seen from the figure that the detection time of Mythril after improvement is within 50 s. It can be completed. The detection is relatively fast and can reach a contract in more than ten seconds. The detection time before the improvement is obviously longer than that of the improved and Oyente, and it is basically about twice the detection time after the improvement. The slowest detection requires time and may take about 90 s, and the detection time trends of the three tools are basically consistent.

Table 4. Average unit detection time for each method.

Experimental Method	Unit Time
Mythril analysis before improvement	59.9 s
Text scheme	28.16 s
Slither	30.9 s
Smart Check	32.3 s
Oyente	35.61 s

shows the average elapsed time of the types of detection contract vulnerabilities. From the results, we can see that the efficiency of the improved Mythril method has improved significantly and does not require the above-mentioned unit detection elapsed time of up to 59.9 s, which has a huge advantage in terms of efficiency.

7. Conclusions

In recent years, blockchain technology has gained widespread attention in both industry and academia. Every day there is an increase in all types of cryptocurrency transactions taking place in the blockchain. All transactions are performed in smart contracts. And, once a smart contract is deployed, the code cannot be modified, even if it is flawed. In the new generation of blockchain-based networks, the increasing popularity of smart contracts has led to a rapid growth in the number of contracts and a large number of security risks, so it is necessary to strengthen the monitoring of their security.

The proposed method in this paper focuses on improving the internal module of Mythril tool to improve the efficiency of detecting smart contract vulnerabilities. By detecting the opcode of the smart contract source code, the smart contract vulnerability is automatically detected, and the smart contract opcode is streamlined, which greatly improves the efficiency and helps to solve the vulnerability of writing smart contracts and reduce the unnecessary loss. Its effectiveness is proven through experiments.