A smart contract vulnerability detection method based on static analysis and large language model fusion

Abstract

The application discloses a smart contract vulnerability detection method based on static analysis and large language model fusion, comprising the following steps: obtaining a smart contract source code to be detected, using a static analysis tool to analyze the pretreated smart contract source code, and generating a static analysis abstract; the smart contract source code and the static analysis abstract information are spliced according to a preset prompt template, and then input into a large language model to obtain a vulnerability detection result. The application effectively integrates the structured priori knowledge of static analysis into the input features, significantly improves the recognition ability of the model for seven core Solidity vulnerabilities, can accurately adapt to the classification task while maintaining the efficiency, and effectively prevents the false negatives, false positives and model security risks.

Description

Technical Field

[0001] This invention belongs to the field of blockchain security technology and relates to a smart contract vulnerability detection method based on the fusion of static analysis (Slither) and large language model. It is applicable to the security detection of smart contracts on blockchain platforms such as Ethereum and BSC (Binance Smart Chain) and can efficiently identify logical vulnerabilities, syntax vulnerabilities and security risks in contracts. Background Technology

[0002] With the rapid development of blockchain technology, smart contracts, as a core component of the blockchain ecosystem, have been widely applied in various fields such as decentralized finance (DeFi), supply chain management, and digital asset trading. A smart contract is an automatically executed contract based on blockchain technology, capable of automatically executing contract terms when specific conditions are met. It features decentralization, immutability, and transparency; therefore, code vulnerabilities can lead to serious consequences such as huge asset losses and transaction failures. In recent years, security incidents caused by smart contract vulnerabilities have occurred frequently, making smart contract security testing a critical issue that urgently needs to be addressed in the blockchain industry.

[0003] Currently, mainstream smart contract vulnerability detection technologies can be categorized into three types: dynamic analysis, formal verification, and static analysis. Dynamic analysis detects vulnerabilities by simulating contract execution, but suffers from incomplete test coverage and difficulty in triggering edge-case vulnerabilities. Formal verification proves contract security based on mathematical logic; while highly accurate, it is complex to operate and requires extensive professional knowledge, making it unsuitable for large-scale contract testing. Static analysis, on the other hand, does not require executing contract code; it identifies vulnerabilities by analyzing source code structure, syntax rules, and logical flow. It boasts advantages such as fast detection speed, low cost, and broad coverage, and has become the mainstream vulnerability detection solution in the industry.

[0004] Slither, currently the most widely used static analysis tool for smart contracts, performs deep analysis of Solidity contracts based on Abstract Syntax Trees (ASTs), enabling it to quickly identify common vulnerabilities such as reentrancy attacks, integer overflows, and improper access control. However, traditional Slither static analysis techniques still have significant shortcomings: limited ability to identify context-dependent and complex logic vulnerabilities, such as logical errors in nested conditional statements and missing permission checks in dynamic calls, easily resulting in missed detections; a high false positive rate, as static analysis rules are difficult to adapt to the differences in business logic across all contracts, often misclassifying legitimate business logic as potential vulnerabilities; and a lack of understanding of vulnerability context and intelligent generation of vulnerability remediation suggestions, resulting in poor readability of detection results for non-experts.

[0005] Large Language Models (LLMs) have demonstrated immense potential in code auditing due to their powerful natural language understanding, code parsing, and logical reasoning capabilities. LLMs can learn contract syntax rules, secure programming patterns, and vulnerability characteristics from massive amounts of code data, assisting in identifying complex logical vulnerabilities and generating targeted remediation solutions. Combining the accuracy of static analysis techniques with the logical reasoning capabilities of LLMs holds promise for solving the problems of false negatives, missed detections, and insufficient intelligence in traditional static analysis tools. However, a mature integration solution has not yet been developed in the current technology, presenting the following challenges: poor compatibility between static analysis results and LLM inputs; insufficient structured parsing capabilities of LLMs for contract code; and a lack of efficient interaction mechanisms in the collaborative detection process between the two.

[0006] Therefore, there is an urgent need to design a smart contract vulnerability detection method based on the fusion of Slither static analysis and large language models to improve the accuracy, comprehensiveness and intelligence of vulnerability detection. Summary of the Invention

[0007] The purpose of this invention is to address the shortcomings of existing technologies by providing a smart contract vulnerability detection method (Slither-LLM based Smart Contract Vulnerability Detection, SLVD) that combines Slither static analysis with large language model technology. This method aims to solve the problems of high false negative rate, high false positive rate, and low intelligence level in traditional smart contract vulnerability detection technologies, thereby improving the accuracy and efficiency of smart contract vulnerability detection.

[0008] To achieve the above objectives, the technical solution provided by this invention is a smart contract vulnerability detection method based on the fusion of static analysis and large language models, including the following:

[0009] Obtain the source code of the smart contract to be tested, and then perform preprocessing;

[0010] The preprocessed smart contract source code is parsed using a static analysis tool (Slither) to identify potential vulnerability features and generate a static analysis summary containing basic contract information, vulnerability locations, and matching rule identifiers.

[0011] The smart contract source code and the static analysis summary information are concatenated according to a preset prompt template to construct an enhanced text input;

[0012] The enhanced text input is processed using a large language model with highly efficient parameter fine-tuning. The logical reasoning capability of the large language model is used to perform in-depth verification and classification of potential vulnerabilities, and the vulnerability detection results of the smart contract are output.

[0013] Furthermore, the result is represented by concatenating the information according to the preset prompt template:

[0014]

[0015] in, This indicates enhanced text input. This represents a summary of the static analysis. This represents the source code of a smart contract. This indicates a string concatenation operation.

[0016] Furthermore, the large language model adopts the Llama series of lightweight models and uses low-rank adaptation (LoRA) for efficient parameter fine-tuning.

[0017] Furthermore, the low-rank adaptation specifically refers to:

[0018] Freeze the original weights of the large language model By introducing a low-rank matrix and Calculate the increment to obtain the fine-tuned new weights. The updated formula is:

[0019]

[0020] in, , , For rank, This is the scaling factor.

[0021] Furthermore, the vulnerability detection results cover at least the following vulnerability types:

[0022] Overflow / Underflow, Re-entrancy, Timestamp Dependency, tx.origin identity impersonation, Unchecked Send, Unhandled Exceptions, and Sybil Attack.

[0023] Secondly, the present invention provides a smart contract vulnerability detection system for implementing the above method, comprising the following modules:

[0024] The data acquisition module is used to acquire the smart contract code to be tested and perform preprocessing.

[0025] The static analysis module uses static analysis tools to generate static analysis summaries from the preprocessed smart contract code.

[0026] The input construction module is used to concatenate the smart contract code to be tested with the static analysis summary into an enhanced text input;

[0027] The inference detection module uses a trained vulnerability detection model to process the enhanced text input and outputs vulnerability detection results.

[0028] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described method.

[0029] Fourthly, the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method.

[0030] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0031] This invention significantly reduces the false positive and false negative rates in vulnerability detection, improves the accuracy of detection results, and solves the problem that existing single static analysis techniques often misjudge legitimate business logic as vulnerabilities due to rule limitations, or miss complex logical defects due to a lack of understanding of the context. This invention uses the initial screening results of static analysis tools as prior knowledge to guide the reasoning of a large language model, and leverages the powerful semantic understanding and logical analysis capabilities of the large language model to deeply verify the initial screening results. This collaborative mechanism can effectively filter false alarms generated by static analysis, while identifying hidden logical vulnerabilities in nested conditional judgments or dynamic calls, thus solving the problem of insufficient detection accuracy of traditional detection methods in complex business scenarios.

[0032] Furthermore, this invention employs low-rank adaptation technology to fine-tune the parameters of large language models. Only the weights of the key projection layers in the attention module need to be updated to enable the model to acquire expertise in smart contract security, avoiding the enormous computational and storage demands of full parameter fine-tuning. Simultaneously, by constructing an enhanced input containing a static analysis summary, the model can be guided to quickly focus on key code snippets, improving inference efficiency while maintaining detection depth. Attached Figure Description

[0033] Figure 1 This is a diagram of the overall architecture of the present invention.

[0034] Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

[0035] The present invention will be further described below with reference to the embodiments and accompanying drawings.

[0036] like Figure 1As shown, the SLVD architecture designed in this invention consists of a data layer, a static analysis layer, a large language model layer, and an application layer. Considering the lightweight deployment requirements, low resource consumption constraints, and detection accuracy goals for smart contract vulnerability detection, this architecture adopts a collaborative working mode between the Slither static analysis component and the Llama 3.2-3B lightweight large model, combined with a data isolation mechanism, adapting to small- to medium-scale server deployment scenarios while ensuring the security and efficiency of the detection process. The functions of each layer are described below:

[0037] (1) Data Layer. The data layer consists of a Solidif dataset adaptation module, a vulnerability feature library, and a detection result storage module. It classifies and processes smart contract samples, vulnerability annotation information, and intermediate detection data in the Solidif dataset to adapt to the input requirements of the Slither static analysis component and the Llama 3.2-3B large model. The core storage includes three types of resources: the Solidif dataset (over 9,000 annotated smart contract samples, covering 7 types of vulnerabilities under the SWC 4.0 standard, encompassing EVM-compatible chain contracts such as Ethereum and BSC), vulnerability feature rules extracted from Solidif samples, historical detection results, and model inference logs. Main functions include format conversion, data cleaning, local storage, and efficient retrieval.

[0038] (2) Static Analysis Layer. Composed of Slither native components and Solidifi rule adaptation module, this is the core functional unit of the architecture. Slither native components perform abstract syntax tree parsing, control flow analysis, and data flow analysis. Based on the vulnerability annotation features of the Solidif dataset, they extend seven types of high-frequency vulnerability custom detection rules to achieve rapid initial screening of potential vulnerabilities. Vulnerability scanning and result preprocessing are implemented by the Solidifi rule execution module and the structured output module, respectively. The rule execution module transforms vulnerability features into executable Slither detection logic, and all rule updates must be verified by Solidifi's newly added sample annotations. After the initial screening is completed, the structured output module encapsulates the results into JSON format data, including core fields such as basic contract information, vulnerability location, matching rule identifier, and related code snippets, providing standardized input for the large language model layer.

[0039] (3) Large Language Model Layer. Composed of the Llama 3.2-3B lightweight model and the Solidif fine-tuning module, deployed on a single GPU (24GB VRAM). It receives potential vulnerability data in JSON format from the static analysis layer. Under low latency, relying on the logical reasoning capabilities fine-tuned from the Solidif dataset, it parses and deeply verifies the core information of the data, identifies complex logical vulnerabilities, filters false positives, and generates executable remediation suggestions. It adopts LoRA lightweight fine-tuning technology, optimizes parameters based on more than 9,000 vulnerability samples in the Solidif dataset, focuses on logical reasoning in the field of smart contract security, and ensures single-node deployment and operation.

[0040] (4) Testing Layer. The core function of the testing layer is to verify the vulnerability detection performance of the SLVDM architecture. A test sample set is constructed based on the Solidif dataset, containing smart contract samples with different vulnerability types and complexities. By comparing the detection results of the SLVDM architecture with the sample annotation results, the four core indicators of detection accuracy, false negative rate, false positive rate, and detection efficiency are quantitatively evaluated. At the same time, stability tests are conducted to verify the fluctuation of the indicators of the architecture under multiple batches of continuous detection scenarios. The test results provide data support for the optimization of Slither detection rules and the adjustment of Llama3.2-3B model parameters, ensuring the reliability and stability of the vulnerability detection performance of the architecture.

[0041] The vulnerability detection results of this invention cover at least the following vulnerability types:

[0042] Overflow / Underflow, Re-entrancy, Timestamp Dependency, tx.origin identity spoofing, Unchecked Send, Unhandled Exceptions, and Sybil Attack; explained in detail below:

[0043] 1. Overflow / Underflow

[0044] This occurs when arithmetic operations exceed the data type's range. For example, subtracting a `uint256` variable to a negative number will result in an extremely large positive value (underflow) due to the unsigned integer property, or adding an integer beyond its maximum value will cause it to cycle back to zero (overflow). Attackers can exploit this to tamper with balances, bypass limit checks, and other critical logic. Solidity 0.8+ has built-in protection, but earlier versions require explicit validation using the SafeMath library. Typical scenarios include token transfers, auction bidding, and dividend calculations.

[0045] 2. Re-entrancy attack

[0046] Attackers recursively trigger the same function via external calls, continuously withdrawing funds before the state is updated. A classic example is The DAO incident: a malicious contract used `call.value()` to repeatedly call `withdraw()` during the withdrawal process, exhausting the funds pool. The key to defense is to "modify the state before transferring funds" and disable recursive call permissions. OpenZeppelin's ReentrancyGuard modifier can block such attack chains through flags.

[0047] 3. Timestamp Dependency

[0048] Block timestamps are controlled by miners (allowing ±15 seconds of deviation) and cannot be used as a trusted source of randomness. Attackers can manipulate timestamps to affect business logic that relies on them, such as ending crowdfunding early, forging deadlines, or interfering with probability algorithms. Solutions include using off-chain signature commitments, multi-signature verification mechanisms, or binding key time nodes to block timestamps rather than absolute timestamps.

[0049] 4. tx.origin identity impersonation

[0050] `tx.origin` points to the original address initiating the transaction, while `msg.sender` reflects the direct caller. If the contract uses `tx.origin` for authorization, users of the intermediary contract will face the risk of unauthorized access—attackers can construct phishing transactions to force victims to pay gas fees. The correct approach is to always use `msg.sender` to verify the caller's identity, avoiding cross-level trust transfer vulnerabilities.

[0051] 5. Unchecked Send failed.

[0052] In EVM, `send()` / `transfer()` only return a boolean value and do not throw exceptions. If the return value is not checked, small transfers may silently fail due to insufficient gas, resulting in funds being permanently locked within the contract. It is recommended to use `call()` in conjunction with the `require(success)` pattern, supplemented by the `safeSend()` wrapper from the Address library, to ensure that each transaction has clear status feedback.

[0053] 6. Unhandled Exceptions

[0054] When external calls (such as cross-contract interactions or on-chain oracle requests) fail, failure to catch the error can lead to transaction rollback and interrupt business processes. More seriously, some frameworks (such as Truffle) do not disclose the specific cause of the error by default, increasing debugging difficulty. It is recommended to add try-catch blocks to record detailed logs and to set up fallback mechanisms for critical operations, such as circuit breakers to suspend high-risk functions.

[0055] 7. Time-of-Check vs. Time-of-Use (TOD)

[0056] In smart contract execution, Time-of-Distance (TOD) attacks are a common security vulnerability. When a contract first verifies a condition (such as sufficient balance), and then before actually using that condition, an attacker can potentially bypass the initial security checks by altering the state within that time window (e.g., modifying the balance through other transactions). This race condition allows malicious users to successfully execute operations that should be blocked, even without sufficient permissions or funds. To prevent such attacks, it is essential to ensure the consistency and atomicity of the state of critical variables, employ appropriate locking mechanisms or transaction management strategies to avoid potential state tampering risks, and utilize techniques such as reentrancy protection to enhance security.

[0057] The method of the present invention will be further described below.

[0058] like Figure 2 As shown, this invention aims to fine-tune the Llama-3.2 pre-trained model by introducing a low-rank adaptation (LoRA) mechanism and using the summary information generated by the Slither static analysis tool as an augmentation input to improve the model's ability to identify seven core Solidity vulnerabilities.

[0059] Step S1: Data Preprocessing and Augmented Input Construction

[0060] The core of this step lies in integrating smart contract source code with professional static analysis results to construct an information-intensive input feature to guide the model's classification decisions.

[0061] 1.1. Raw Data Processing

[0062] Experimental Dataset From smart contract code Summary of its corresponding pre-computation Slither static analysis Composition. For each sample Extract its vulnerability category tags And through mapping Convert to integer labels ,in In this embodiment, the total number of categories is [number]. .

[0063] 1.2. Enhanced Input Construction

[0064] To maximize the use of structured knowledge from static analysis tools, a prompt template is designed to present smart contract code. and static analysis summary Concatenate into a single enhanced text input .

[0065]

[0066] in, This indicates a string concatenation operation. This format places static analysis warnings before the code, guiding the model to prioritize potential risks.

[0067] 1.3. Batch Processing

[0068] Enhanced Input go through After word segmentation, an input ID sequence is generated. and attention mask During the batching phase, use the populated ID ( Perform right padding to generate batch tensors. , ,and .

[0069]

[0070] in, This represents the set of input token index sequences for each sample x in the current batch; This represents the set of valid content attention mask sequences for each sample x in the current batch. This represents the set of true vulnerability category labels for each sample x in the current batch.

[0071] Step S2: LoRA Model Architecture and Efficient Parameter Fine-Tuning

[0072] This step details the loading of the Llama-3.2 model and the configuration of the LoRA adapter to achieve memory-efficient fine-tuning.

[0073] 2.1. Model Initialization

[0074] Loading pre-trained Model And configure it as a sequence classification task ( Model usage Precision loading. Since the task is classification, ensure the model header includes a parameter for... Linear layers for category classification (typically labeled score layers):

[0075]

[0076] in It is the last hidden state of the Llama model; The classification weight matrix is ​​responsible for assigning weights to the high-dimensional feature vectors output by the Llama model. Mapped to 7 classification dimensions; The classification bias vector is used to adjust the decision preference for each category, thereby improving the generalization ability of the classifier.

[0077] 2.2. LoRA Adapter Configuration

[0078] LoRA introduces a low-rank matrix and Update the pre-trained weights. Only update the key projection layers of the self-attention module. Adaptation is required.

[0079] The weight update formula is:

[0080]

[0081] in: , (Trainable), rank 2. Scaling factor scaling factor Used to adjust the strength of low-rank updates. Query matrix. Used to extract the information features that the current token is looking for. Key matrix. Used to represent the information features that the current token can "provide" to other tokens. Value matrix. Stores the actual semantic content of the token, when... and When a match is successful, the corresponding The information will be extracted in a weighted manner. Output matrix. Responsible for performing a linear transformation on the result of merging multi-head attention, mapping it back to the original dimensions. Weight update increment. Through the low-rank matrix. and product It is constructed to capture task-specific knowledge about smart contract vulnerability features without changing the pre-trained weights.

[0082] 2.3. Classification Head Training

[0083] To ensure the effectiveness of the classification task, the classification head will be... Clearly included List. This means that during the LoRA fine-tuning process, It is one of the few native weights that have not been frozen, ensuring that the classification layer can adapt to downstream tasks.

[0084] Step S3: Distributed Training and Optimization Strategy

[0085] This step describes the parallelization, loss calculation, gradient management, and learning rate scheduling mechanisms during model training.

[0086] 3.1. Distributed Data Parallelism (DDP)

[0087] Training adopted Framework, Model It is packaged and deployed on multiple GPUs.

[0088] 3.2. Loss Function and Gradient Accumulation

[0089] Using the standard cross-entropy loss function For batches The total loss is:

[0090]

[0091] in Integer Labels The model represents a single sample The original output vector.

[0092] To overcome GPU memory limitations and simulate larger batch effects, gradient accumulation is applied. The total effective batch size of the model is: .loss Scaled during backpropagation: .

[0093] 3.3. Optimizer and Learning Rate Scheduling

[0094] The optimizer uses Learning rate A linear preheating and decay scheduler is used. ).

[0095] Preheating steps ( ): 100 steps.

[0096] Total steps:

[0097] Learning rate With step count The changes are as follows:

[0098]

[0099] Step S4: Performance Evaluation

[0100] 4.1. Performance Evaluation Metrics

[0101] Model performance on the validation set Above through average loss and overall accuracy Perform measurement.

[0102]

[0103] in The Logits output by the model, This is an indicator function.

[0104] 4.2. Optimal Model Saving Mechanism

[0105] An optimal model saving strategy guided by the principle of early stopping is adopted. In each... At the end, only if the current validation set accuracy is... Exceeding the highest historical accuracy Only when this happens will the model weights be persisted.

[0106]

[0107] This mechanism ensures that the saved model is the checkpoint with the best generalization performance.

Claims

1. A smart contract vulnerability detection method based on the fusion of static analysis and large language model, characterized in that, Includes the following steps: Obtain the source code of the smart contract to be tested, and then perform preprocessing; Static analysis tools are used to parse the preprocessed smart contract source code, identify potential vulnerability features, and generate a static analysis summary containing basic contract information, vulnerability locations, and matching rule identifiers. The smart contract source code and the static analysis summary information are concatenated according to a preset prompt template to construct an enhanced text input; The enhanced text input is processed using a large language model with highly efficient parameter fine-tuning. The logical reasoning capability of the large language model is used to perform in-depth verification and classification of potential vulnerabilities, and the vulnerability detection results of the smart contract are output.

2. The smart contract vulnerability detection method based on the fusion of static analysis and large language model as described in claim 1, characterized in that, The following is a representation based on the preset prompt template: in, This indicates enhanced text input. This represents a summary of the static analysis. This represents the source code of a smart contract. This indicates a string concatenation operation.

3. The smart contract vulnerability detection method based on the fusion of static analysis and large language model as described in claim 1, characterized in that, The large language model adopts the Llama series of lightweight models and uses low-rank adaptation for efficient parameter fine-tuning.

4. The smart contract vulnerability detection method based on the fusion of static analysis and large language model as described in claim 3, characterized in that, The low-rank adaptation specifically refers to: Freeze weight By introducing a low-rank matrix and For pre-trained weights The update is performed using the following formula: in, , , For rank, This is the scaling factor.

5. The smart contract vulnerability detection method based on the fusion of static analysis and large language model as described in claim 1, characterized in that, The vulnerability detection results cover at least the following vulnerability types: Overflow / underflow, reentrancy attack, timestamp dependency, tx.origin identity impersonation, unverified send failure, unhandled exception, and Sybil attack.

6. A smart contract vulnerability detection system implementing the method as described in any one of claims 1-5, characterized in that, Includes the following modules: The data acquisition module is used to acquire the smart contract code to be tested and perform preprocessing. The static analysis module uses static analysis tools to generate static analysis summaries from the preprocessed smart contract code. The input construction module is used to concatenate the smart contract code to be tested with the static analysis summary into an enhanced text input; The inference detection module uses a trained vulnerability detection model to process the enhanced text input and outputs vulnerability detection results.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-5.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1-5.

Images