Intelligent contract vulnerability detection method and system based on type perception and graph enhancement

Abstract

The present application belongs to the technical field of smart contract vulnerability detection, and particularly relates to a smart contract vulnerability detection method and system based on type perception and graph enhancement. Firstly, the vulnerability types of the smart contract to be tested are quickly classified. Then, corresponding graph structures are constructed for different types of vulnerabilities. In order to solve the problem of semantic fragmentation between different graph structures, graph fusion operation is performed to obtain a fused semantic graph. The information of the fused semantic graph is embedded into the prompt to enhance the understanding ability of the large language model for the contract, guide the model to conduct deeper semantic understanding and vulnerability identification, and the addition of the fused semantic graph enables the large language model to more accurately identify the multi-vulnerability coupling path. Finally, the cross-validation and logical questioning of the detection results output by the large language model are performed to further improve the credibility and robustness of vulnerability identification.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of smart contract vulnerability detection, and particularly relates to a smart contract vulnerability detection method and system based on type perception and graph enhancement. BACKGROUND

[0002] When a traditional vulnerability detection tool is used to detect smart contract vulnerabilities, the contract has problems of insufficient structure modeling and path coverage capability. The traditional vulnerability detection tool analyzes the contract based on fixed rule templates and function-level granularity. This method is difficult to effectively express the state dependency relationship between functions and the data flow across the call chain, and is particularly weak in identifying reentrant attacks that need to simulate dynamic behaviors (such as callback calls caused by calls). Therefore, it is easy to have a missed report problem. When a large language model is used for vulnerability detection, although the model has certain semantic understanding and natural language reasoning ability, in the absence of structured prompts for the contract, the model is easily misled by surface information such as variable naming and context patterns, resulting in misjudgment of vulnerability types. At the same time, when a single model is used for vulnerability detection, the single model architecture lacks reflection on the results and analysis and verification of the reasoning path, and the output results lack effective verification, so it is easy to cause the vulnerability detection results of the model to have missed reports and false positives.

[0003] Therefore, there is an urgent need for a new detection method to make up for the blind spots of traditional methods and the limitations of reasoning. SUMMARY

[0004] To solve the problems raised in the background art, the application provides a smart contract vulnerability detection method and system based on type perception and graph enhancement.

[0005] The technical solutions of the application are as follows:

[0006] The application provides a smart contract vulnerability detection method based on type perception and graph enhancement, comprising:

[0007] S1: Preliminary judgment is performed on the to-be-tested smart contract, possible vulnerability types are identified, and the to-be-tested smart contract is divided into predefined vulnerability types;

[0008] The predefined vulnerability types include reentrant attacks, timestamp dependencies, integer overflows, and / or delegation call vulnerabilities;

[0009] S2: For different types of vulnerabilities, corresponding graph structure extraction operations are performed to construct a graph structure adapted to the vulnerability type;

[0010] All nodes of the graph structure perform unified index coding, and the coding format is [graph type]-[node ID]-[source code location]; At the same time, a node attribute database is established to record the functional attribute characteristics, associated source code segment characteristics, and dependency relationship characteristics of each node;

[0011] Based on the index and node attribute data, the nodes of different graph structures are sequentially associated according to the priority order of the source code location matching degree, the function dependency matching degree and the semantic vector matching degree, to obtain corresponding source code location association, dependency association and semantic association node types, and the nodes are connected according to the node types to generate a fused semantic graph representation;

[0012] The fused semantic graph representation is spliced with the to-be-tested smart contract source code and the structured prompt word to generate a spliced prompt word;

[0013] S3: calling a large language model to perform structured semantic enhancement analysis on the spliced prompt word and outputting a detection result;

[0014] S4: the detection result is verified by a verification model, to generate a questioning data and feedback to the large language model;

[0015] After the spliced prompt word and the questioning data are fused, the large language model dynamically adjusts the attention weight of each path of the fused data by using an attention mechanism, re-outputs a detection result, executes S4, and stops until no questioning data is generated or a preset round is reached.

[0016] S2: performing corresponding graph structure extraction operations on different types of vulnerabilities to construct graph structures adapted to the types of vulnerabilities, specifically:

[0017] The reentrant attack vulnerability uses a data flow graph and a control flow graph, the timestamp dependency vulnerability uses a contract tree and an abstract syntax tree, the integer overflow vulnerability uses a control flow graph and an abstract syntax tree, and the delegate call vulnerability uses a dependency abstract syntax tree for modeling.

[0018] S2: based on the index and node attribute data, the nodes of different graph structures are sequentially associated according to the priority order of the source code location matching degree, the function dependency matching degree and the semantic vector matching degree, to obtain corresponding source code location association, dependency association and semantic association node types, specifically:

[0019] For any two nodes of different graph structures, the source code location field in the index is parsed to extract the start line number and the end line number; the overlap degree is calculated according to the formula: overlap degree = overlapping line number / total length of line number interval of two nodes, and if the overlap degree is greater than a preset overlap degree, the node type is marked as a source code location association node;

[0020] If the overlap degree is not greater than the preset overlap degree, the functional attribute feature is extracted from the node attribute database, and an "operation-operated" role pair is established; the "operation-operated" dependency relationship of two different graph structure nodes is traced back in reverse through the call stack and the data flow chain, a dependency chain is obtained, the functional dependency matching degree is calculated according to the length of the dependency chain, and if the functional dependency matching degree is greater than the preset functional dependency matching degree, the node type is marked as a dependency association node;

[0021] If the functional dependency matching degree is not greater than the preset functional dependency matching degree, the associated source code segment feature of the node is extracted, the cosine similarity is calculated after being converted into a vector, and the cosine similarity is used as a semantic vector matching degree, and the type of the node with a cosine similarity greater than the preset similarity is marked as a semantic association node.

[0022] S2 according to the node type, the nodes are connected, specifically:

[0023] For the source code position association node, a mutual pointing edge is established between the two nodes;

[0024] For the dependency association node, a one-way edge is established according to the dependency direction and in accordance with the "dependency source-dependency target" rule;

[0025] For the semantic association node, a one-way "semantic mapping" edge is established from the node with clear semantics to the semantic related node.

[0026] S2 the functional attribute feature is a function definition, variable assignment, conditional judgment, external call, inheritance declaration;

[0027] The associated source code segment feature is a function signature, variable name, operator, conditional expression, and call parameter;

[0028] The dependency relationship feature is a called function, an affected variable, a triggered event, a parameter dependency, and an inheritance dependency.

[0029] S3 the call of the large language model is used for structured semantic enhancement analysis of the spliced prompt word, specifically:

[0030] If the vulnerability type is a reentrant attack or an integer overflow vulnerability, the deepseek-reasoner large language model is called;

[0031] If the vulnerability type is a timestamp dependency vulnerability, the Grok-3 large language model is called;

[0032] If the vulnerability type is a delegate call vulnerability, the GPT-4o large language model is called.

[0033] S1 the identification of possible vulnerability types is to identify potential vulnerabilities in the contract based on semantic understanding of the contract by using a type-aware model;

[0034] The type-aware model is obtained by training and LoRA fine-tuning by using a training data set containing a triple of [source code location, vulnerability type, semantic interpretation text].

[0035] The detection result includes: vulnerability detection type, vulnerability location, triggered logic path and explanatory text.

[0036] The application also provides a type-aware and graph-enhanced intelligent contract vulnerability detection system, comprising:

[0037] The vulnerability classification module: preliminarily judges the to-be-tested intelligent contract, identifies possible vulnerability types, and divides them into predefined vulnerability types;

[0038] The predefined vulnerability types include: re-entrant attack, timestamp dependence, integer overflow and / or delegation call vulnerability;

[0039] The graph structure enhancement module: performs corresponding graph structure extraction operations on different types of vulnerabilities to construct graph structures adapted to the vulnerability types;

[0040] All nodes of the graph structure perform unified index coding, and the coding format is [graph type]-[node ID]-[source code location]; meanwhile, a node attribute database is established to record the functional attribute characteristics, associated source code segment characteristics and dependency relationship characteristics of each node;

[0041] Based on the index and node attribute data, the nodes of different graph structures are sequentially associated according to the priority order of source code location matching degree, functional dependency matching degree and semantic vector matching degree, to obtain corresponding source code location association, dependency association and semantic association node types, and the nodes are connected according to the node types to generate a fused semantic graph representation;

[0042] The fused semantic graph representation is spliced with the to-be-tested intelligent contract source code and structured prompt words to generate spliced prompt words;

[0043] The detection result output module: calls a large language model to perform structured semantic enhancement analysis on the spliced prompt words and outputs the detection result;

[0044] The challenge mechanism module: the detection result is reviewed by a verification model, challenge data is generated, and feedback is fed back to the large language model;

[0045] After the spliced prompt words and the challenge data are fused, the large language model dynamically adjusts the attention weights of each path of the fused data using an attention mechanism, re-outputs the detection result, enters the challenge mechanism module, and continues until no challenge data is generated or the preset round is reached.

[0046] Advantages

[0047] The application firstly classifies the vulnerability types of the to-be-tested smart contract, then constructs corresponding graph structures for different types of vulnerabilities, in order to solve the problem of semantic disconnection between different graph structures, performs graph fusion operation, obtains a fused semantic graph, embeds the information of the fused semantic graph into the prompt text, enhances the understanding ability of the large language model to the contract, guides the model to perform deeper semantic understanding and vulnerability identification, and the addition of the fused semantic graph enables the large language model to more accurately identify the multi-vulnerability coupling path, finally, through cross-validation and logical questioning of the detection results output by the large language model, the credibility and robustness of vulnerability identification are further improved. BRIEF DESCRIPTION OF DRAWINGS

[0048] Figure 1 The comparison line chart of the vulnerability detection performance of the system of the application and the existing large language model on the same data set. DETAILED DESCRIPTION

[0049] The following examples are intended to illustrate the application, but not further limit the application.

[0050] The application provides a smart contract vulnerability detection method based on type perception and graph enhancement, comprising:

[0051] S1: classifying the to-be-tested smart contract, identifying possible vulnerability types, and dividing them into predefined vulnerability types;

[0052] The predefined vulnerability types include reentrant attack, timestamp dependence, integer overflow and / or delegation call vulnerability.

[0053] In the vulnerability classification stage, firstly, the identification of possible vulnerability types is used to identify potential vulnerabilities in the contract based on the semantic understanding of the contract by using a type perception model;

[0054] The type perception model is obtained by training and LoRA fine-tuning using a training data set containing [source code location, vulnerability type, semantic explanation text] triplets.

[0055] Specifically, in order to enhance the vulnerability detection capability of the type-aware model in the field of smart contracts, the present application collects a large number of real smart contract samples from platforms such as GitHub, and constructs a structured training set containing 8000 samples. In this data set, although most of the contracts have explicit vulnerability type labels, there is a lack of structured explanation of the causes of the vulnerabilities, logical errors, and attack paths. This lack makes it difficult for the data set to meet the needs of model training at the semantic level. Therefore, the present application first generates preliminary vulnerability explanations from the Claude model, which elaborates on the triggering conditions of the vulnerabilities, potential attack paths, and semantic logic-related security risks. Then, the Qwen-2 model is used for language optimization and logic reconstruction to ensure the accuracy and organization of the explanation content. Finally, a training data set containing [source code location, vulnerability type, semantic explanation text] triplets is constructed.

[0056] Next, the parameter-efficient fine-tuning method LoRA (Low-Rank Adaptation) is used. This method does not directly modify the parameters of the pre-trained model, but only injects low-rank trainable modules into key parts of the Transformer network, such as the Query and Value matrices in the Attention layer, thereby achieving efficient fine-tuning with minimal parameter overhead.

[0057] Through classification analysis, the present application realizes rapid perception and classification of contract vulnerability risks, not only improving the overall analysis efficiency, but also providing targeted input configuration for the subsequent graph structure enhancement analysis stage, thereby realizing an efficient and modularized vulnerability detection process.

[0058] S2: For different types of vulnerabilities, perform corresponding graph structure extraction operations to construct graph structures adapted to the types of vulnerabilities;

[0059] All nodes of the graph structure perform unified index encoding, and the encoding format is [graph type]-[node ID]-[source code location]. At the same time, a node attribute database is established to record the functional attribute characteristics, associated source code segment characteristics, and dependency relationship characteristics of each node;

[0060] Based on the index and node attribute data, the nodes of different graph structures are sequentially associated according to the priority order of source code location matching degree, functional dependency matching degree, and semantic vector matching degree, to obtain corresponding source code location association, dependency association, and semantic association node types. According to the node types, the nodes are connected to generate a fused semantic graph representation;

[0061] The fused semantic graph representation is spliced with the source code and structured prompt words of the smart contract to be tested to generate spliced prompt words.

[0062] In the graph structure enhancement stage, first, the different types of vulnerabilities are executed corresponding graph structure extraction operations, and the graph structure suitable for the vulnerability type is constructed, specifically:

[0063] The reentrant attack vulnerability is modeled using a data flow graph and a control flow graph. The control flow graph captures the loop, call sequence and other control logic in the function execution path, and the data flow graph reveals the dependency changes between key variables such as balance and address, which helps to identify typical reentrant attack paths.

[0064] The timestamp-dependent vulnerability uses a contract tree and an abstract syntax tree for modeling. By capturing the nesting relationship of context-dependent expressions such as block.timestamp In the code structure, it helps to understand the excessive dependence of logic branches on on-chain time data during detection.

[0065] The integer overflow vulnerability uses a control flow graph and an abstract syntax tree for modeling, which is used to capture the use path of integer variables in assignment, calculation and condition judgment, helping to identify unchecked mathematical operations or out-of-bound assignments.

[0066] The delegation call vulnerability uses a dependency abstract syntax tree for modeling. This structure introduces explicit and implicit dependency information, such as external call dependencies, storage variable overwrite paths, etc., based on the standard abstract syntax tree, revealing delegatecall The semantic risks caused by changes in the execution environment.

[0067] The introduction of the graph structure extraction operation of the present application enables the subsequent large language model not only to "understand" the surface statements of the contract, but also to "understand" the internal running logic, thereby greatly improving the accuracy and interpretability of vulnerability detection.

[0068] In order to solve the problem of semantic fragmentation between different graph structures (such as control flow graph, data flow graph and abstract syntax tree), then, the graph fusion operation is performed, specifically as follows:

[0069] Preferably, the function attribute feature S2 is function definition, variable assignment, condition judgment, external call, inheritance declaration, used to describe the core role of the node in the smart contract logic;

[0070] The associated source code segment feature is a function signature, a variable name, an operator, a conditional expression, and a call parameter, which directly reflects the semantic information of the node;

[0071] The dependency feature is a function call, an impact variable, a trigger event, a parameter dependency, and an inheritance dependency, used to describe the interaction logic of the node with other nodes, and embodies the relevance of code execution.

[0072] Preferably, S2 is based on the index and node attribute data, the nodes of different graph structures are associated in turn according to the priority order of the source code location matching degree, the function dependency matching degree and the semantic vector matching degree, and the corresponding source code location association, dependency association and semantic association node types are obtained, and specifically:

[0073] For any two nodes of different graph structures, the start line number and the end line number are extracted by analyzing the source code location field in the index; the overlap degree is calculated according to the formula: overlap degree = overlapping line number / total length of line number interval of two nodes, if the overlap degree is greater than a preset overlap degree, the node type is marked as a source code location association node;

[0074] If the overlap degree is not greater than the preset overlap degree, the function attribute features are extracted from the node attribute database, and a "operation-operated" role pair (such as "function call"→"variable assignment", "conditional judgment"→"arithmetic operation") is established; the "operation-operated" dependency relationship of the two nodes of different graph structures is traced back in reverse through the call stack and the data flow chain, and a dependency chain is obtained (such as the execution node (function attribute: function call) of withdraw() in the control flow graph has a dependency relationship of "being called by fallback()", and the update node (function attribute: variable assignment) of balance in the data flow graph has a dependency relationship of "being affected by withdraw()", so the two nodes form an indirect dependency chain through withdraw()), the function dependency matching degree is calculated according to the chain length of the dependency chain, if the function dependency matching degree is greater than a preset function dependency matching degree, the node type is marked as a dependency association node;

[0075] If the function dependency matching degree is not greater than the preset function dependency matching degree, the associated source code segment features of the nodes are extracted, the cosine similarity is calculated after being converted into vectors, and the cosine similarity is taken as the semantic vector matching degree, and the type of the node with a cosine similarity greater than a preset similarity is marked as a semantic association node.

[0076] Through the above operation, the nodes of different graph structures are accurately associated into three types of node pairs, which not only ensures the rigor of the association (based on the source code location and the dependency chain), but also takes into account the potential connection at the semantic level (based on the vector matching), and lays a structured foundation for the construction of the fused semantic graph.

[0077] Further, S2 is based on the node type, and the nodes are connected, and specifically:

[0078] For the source code location association node, a mutual pointing edge is established between the two nodes, such as the function execution node of the control flow graph ↔ the function definition node of the abstract syntax tree;

[0079] For dependency association nodes, according to the dependency direction, follow the rule of "dependency source → dependency target", establish a one-way edge, such as function A calling function B (functional dependency), and the edge type is marked as "call dependency";

[0080] For semantic association nodes, establish a one-way "semantic mapping" edge from a node with clear semantics to a semantically related node, such as the block.timestamp node of the abstract syntax tree pointing to the time judgment node of the control flow graph.

[0081] The weight of the edge can be set according to the actual situation. For example, the weight of the edge of the source code location association node can be set to an upper limit value of 5, and the weight of the edge of the dependency association node can be dynamically adjusted according to the chain length (chain length 1 → 4, chain length 2 → 3, chain length 3 → 2).

[0082] Through the above steps, the originally fragmented graph structure is integrated into an associated network with unified semantics, i.e. the fusion semantic graph, so that the large language model can more accurately identify multi-vulnerability coupling paths.

[0083] Finally, the fusion semantic graph representation is spliced with the source code of the smart contract to be tested and the structured prompt word to generate a spliced prompt word. The fusion semantic graph representation, such as the control flow graph path sequence, the abstract syntax tree nested structure, and the annotation node in the dependency abstract syntax tree, etc. The structured prompt word is used to guide the model to focus on the vulnerability-related features reflected by the graph structure.

[0084] For example, when dealing with a reentrant attack vulnerability, the structured prompt word is: "You will analyze a smart contract. The control flow graph and data flow graph of the contract are shown below. Please analyze whether there is a reentrant attack vulnerability based on these structural information, and point out the key call path, state variable position and attack possibility. If there is a vulnerability, please provide a detailed explanation."

[0085] S3: Call the large language model to perform structured semantic enhancement analysis on the spliced prompt word and output the detection result.

[0086] Specifically:

[0087] If the vulnerability type is a reentrant attack or integer overflow vulnerability, call the deepseek-reasoner large language model;

[0088] If the vulnerability type is a timestamp dependency vulnerability, call the Grok-3 large language model;

[0089] If the vulnerability type is a delegate call vulnerability, call the GPT-4o large language model.

[0090] The present application is based on a self-built four-type smart contract vulnerability dataset, and the detection capabilities of multiple mainstream large language models in different vulnerability type tasks are systematically evaluated. The experimental results show that the performance of different models in various tasks is significantly different. For example, in the reentrant and integer overflow vulnerability detection tasks with complex control flow paths and deep call levels, deepseek-reasoner shows high accuracy and logical explanation ability, and is particularly good at analyzing multivariate dependencies and condition trigger chains. In the global variable judgment on the dependency chain and the timestamp dependency involving multiple logic branches, the context retention ability and conditional reasoning ability of Grok-3 are the most stable. For the delegation call vulnerability, due to its complex cross-contract call relationship and context switching requirements, GPT-4o has obvious advantages over other models in identifying key risk points such as storage pollution and permission transfer, thanks to its strong generalization ability and multi-level semantic modeling ability.

[0091] Preferably, the detection result includes vulnerability detection type, vulnerability location, triggered logic path, and explanatory text. The detection result can be presented in the form of a structured analysis report.

[0092] In addition, to enhance the semantic understanding and knowledge generalization ability of large language models in smart contract vulnerability detection tasks, the present application also constructs an external knowledge database based on a retrieval-enhanced generation mechanism. In order to make the database content computable and retrievable, the vulnerability knowledge text is converted into structured semantic index through a semantic embedding mechanism. When the model performs a specific vulnerability detection task, it can dynamically retrieve highly relevant knowledge paragraphs from the knowledge base according to the current prompt or contract context, thereby enhancing the model's understanding ability of vulnerability mechanisms in complex, ambiguous, or boundary scenarios.

[0093] S4: The detection result is verified by a verification model (such as Claude-3-Sonnet model) to generate questioning data and feedback to the large language model;

[0094] After splicing the prompt and the fused questioning data, the large language model dynamically adjusts the attention weight of each path of the fused data using the attention mechanism, re-outputs the detection result, and executes S4 until no more questioning data is generated or the preset round is reached.

[0095] Considering that a single large language model may miss key information, make mistakes, or not fully explain the problem when performing a single round of reasoning, the present application introduces a questioning mechanism after outputting the detection result to deeply question and feedback the analysis result, in order to make up for the possible shortcomings of a single model.

[0096] Among them, the attention mechanism is introduced to dynamically adjust the attention weight of each path of the fused data, and in the reasoning process, the paths highly related to the vulnerability propagation are given priority, while the structural parts irrelevant to the detection target are weakened.

[0097] A typical interaction example is as follows: for the analysis report "The contract has a delegatecall vulnerability at line 34 because the calling address is not checked.", the Claude-3-Sonnet model will then ask: "Is the target address of the delegatecall still replaceable externally? Is there a fallback function used in conjunction?" The large language model will then revise according to the query and supplement the explanation "Although the target address is a constant, its value comes from the constructor input and may be controlled by the deployer." Finally, the Claude-3-Sonnet model confirms again and indicates "The explanation is sufficient, the vulnerability is valid, and the report is passed." Through this cross-examination mechanism between models, the invention can effectively make up for the shortcomings of single-model explanation, and realize the "questioning-reconstruction-confirmation" three-stage closed loop of vulnerability logic.

[0098] The invention first classifies the vulnerability types of the to-be-tested smart contract, then constructs corresponding graph structures for different types of vulnerabilities, in order to solve the problem of semantic fragmentation between different graph structures, performs graph fusion operation to obtain a fused semantic graph, and then embeds the above graph structure information into the prompt to enhance the understanding ability of the large language model to the contract, guide the model to conduct deeper semantic understanding and vulnerability identification, and enable the large language model to more accurately identify multi-vulnerability coupling paths, finally, cross-verify and logically question the detection results output by the large language model, further improve the credibility and robustness of vulnerability identification.

[0099] The invention also provides a smart contract vulnerability detection system based on type perception and graph enhancement, comprising:

[0100] The vulnerability classification module: preliminarily judges the to-be-tested smart contract, identifies possible vulnerability types, and divides them into predefined vulnerability types;

[0101] The predefined vulnerability types include: reentrant attack, timestamp dependency, integer overflow and / or delegate call vulnerability;

[0102] The graph structure enhancement module: performs corresponding graph structure extraction operation on different types of vulnerabilities to construct graph structures adapted to the vulnerability types;

[0103] All nodes of the graph structure perform unified index coding, and the coding format is [graph type]-[node ID]-[source code location]; at the same time, a node attribute database is established to record the functional attribute characteristics, associated source code segment characteristics and dependency relationship characteristics of each node;

[0104] Based on the index and node attribute data, the nodes of different graph structures are sequentially associated according to the priority order of source code location matching degree, function dependency matching degree and semantic vector matching degree, to obtain corresponding source code location association, dependency association and semantic association node types, and the nodes are connected according to the node types to generate a fusion semantic graph representation;

[0105] The fusion semantic graph representation is spliced with the to-be-tested smart contract source code and the structured prompt word to generate a spliced prompt word;

[0106] The detection result output module: calling the large language model to perform structured semantic enhancement analysis on the spliced prompt word and outputting the detection result;

[0107] The challenge mechanism module: the detection result is reviewed by the verification model, challenge data is generated, and the challenge data is fed back to the large language model;

[0108] After the spliced prompt word and the challenge data are fused, the large language model dynamically adjusts the attention weight of each path of the fused data by using the attention mechanism, re-outputs the detection result, enters the challenge mechanism module, and continues until no challenge data is generated or the preset round is reached.

[0109] Experimental setup and result analysis

[0110] The present application tests a data set containing four common types of smart contract vulnerabilities. Through analysis of the test results, the following research questions are answered:

[0111] RQ1: How does the vulnerability detection method of the present application perform compared to traditional vulnerability detection tools?

[0112] RQ2: Does the vulnerability detection system of the present application have more outstanding performance compared to existing advanced large language models?

[0113] RQ3: What is the impact of the graph structure enhancement mechanism on the performance of vulnerability detection?

[0114] Data set

[0115] In this experiment, part of the contracts in the SmartBugs Curated data set were selected to evaluate and compare the vulnerability detection effect of the system of the present application. SmartBugs Curated is a widely used Solidity smart contract data set, which contains labeled information of various common vulnerability types.

[0116] The data used in the present application includes four representative smart contract vulnerabilities, which are: re-entrant attack, timestamp dependency, integer overflow and delegation call vulnerability. The analysis of the present experiment is carried out at the source code level. A total of 10293 smart contracts, of which a total of 3381 contracts are marked as containing security vulnerabilities.

[0117] But among the four types of vulnerabilities selected by the present experiment, the number of vulnerable contracts of each type is relatively balanced. This distribution ensures that the performance comparison between different vulnerability types is fair and meaningful. To further ensure the reliability of the annotation, 30% of the contracts were randomly selected for manual verification, achieving an annotation accuracy of 94.31%.

[0118] Experiment

[0119] In order to make a reasonable analysis and evaluation of the vulnerability detection results of the vulnerability detection system of the present application, precision (Precision), recall (Recall) and F1 score (F1-score) are selected as evaluation indicators. Through these indicators, the vulnerability detection effect is reflected. These three indicators are widely used in vulnerability detection, classification tasks and information retrieval fields, and can fully reflect the performance of the tool in the vulnerability detection task.

[0120] When evaluating the performance of vulnerability detection, the detection results are compared with the true labels, and based on this, four types of basic statistics are calculated:

[0121] True positive (True Positive, TP): the number of contracts with vulnerabilities correctly identified by the system, i.e. the contract itself has vulnerabilities, and the system also detects the vulnerabilities;

[0122] False positive (False Positive, FP): the number of contracts that the system incorrectly judges as containing vulnerabilities, which actually do not contain vulnerabilities, and are false positives;

[0123] True negative (True Negative, TN): the number of contracts that the system correctly judges as not containing vulnerabilities;

[0124] False negative (False Negative, FN): the number of contracts with vulnerabilities that the system fails to identify, i.e. the contract actually contains vulnerabilities, but the system fails to detect, which is a false negative.

[0125] On this basis, precision (Precision) is used to measure how many of all the vulnerabilities identified by the system are actually present. The higher the precision, the fewer the false positives, and the more reliable the detection results. The calculation formula is:

[0126]

[0127] Recall is used to measure the proportion of all real vulnerabilities that the system successfully identifies. The higher the recall, the fewer the false negatives and the stronger the coverage. It is defined as:

[0128]

[0129] In actual situations, precision and recall are usually trade-offs, so F1 score is introduced as the harmonic mean of the two to comprehensively reflect the overall detection performance of the system. The calculation formula is:

[0130]

[0131] By calculating Precision, Recall and F1-score on multiple vulnerability types and comparing them, the detection ability and practicality of the vulnerability detection system in different tasks can be comprehensively evaluated.

[0132] Experimental analysis

[0133] RQ1: How does the vulnerability detection method of the present invention perform compared to traditional vulnerability detection tools?

[0134] In the detection task of four typical smart contract vulnerabilities, namely reentrancy attack, timestamp dependency, integer overflow and delegate call, the performance of the vulnerability detection system of the present invention and eight mainstream traditional detection tools was systematically compared, and the evaluation results are shown in Table 1. Experimental data shows that the detection performance of the vulnerability detection system of the present invention on all vulnerability types is better than that of traditional detection tools, showing strong generalization ability and robustness.

[0135] Table 1 Comparison of vulnerability detection effects of the vulnerability detection system of the present invention and traditional vulnerability detection tools in the same data set

[0136]

[0137] Specifically, the F1 score of the vulnerability detection system of the present invention on the four vulnerabilities is as follows: reentrancy attack 73.67%, timestamp dependency 77.02%, integer overflow 96.06%, and delegate call 74.88%. It leads other tools in all indicators. Especially in the vulnerability type with complex structure and implicit semantics (such as delegate call and reentrancy attack), the vulnerability detection system of the present invention still maintains high recall (97.19% and 96.11% respectively) and good precision, indicating that it has deep semantic understanding and cross-function information reasoning ability.

[0138] In contrast, traditional tools have significant imbalance and performance bottlenecks in vulnerability detection tasks. For example, smartcheck, as an AST rule-based static analysis tool, has a simplified detection logic that mainly relies on pattern matching, and thus performs poorly when facing semantically complex or long call chain vulnerabilities, resulting in F1 scores of only 40.71% and 51.12% for reentrancy attack and delegate call vulnerabilities. Mythril uses a symbolic execution mechanism, which theoretically has path traversal capabilities, but in practical applications, it is often limited by path explosion and incomplete environment modeling. Its F1 for integer overflow vulnerabilities is only 62.50%, and its performance on other types is also unstable. Slither, although it combines control flow and inheritance relationship static analysis techniques and internally models data flow and pollution paths, is still essentially rule-driven and cannot break through the limitations of semantic understanding and context dependence, resulting in F1 scores of only 68.25% and 62.42% for timestamp-dependent vulnerabilities and delegate call vulnerabilities. Osiris, as a tool focusing on EVM bytecode-level data flow analysis, is good at identifying low-level stack operation patterns and instruction exception paths, and performs well in integer overflow and reentrancy attack vulnerabilities. Its F1 scores for delegate call and integer overflow vulnerabilities are 61.51% and 57.34%, respectively, which are slightly better than some traditional tools, but there are still unavoidable shortcomings in semantic expression and structure modeling, and the processing capacity for context dependence is relatively weak. Securify, although it introduces a formal verification mechanism based on property graphs and uses declarative languages to symbolically model contract execution paths, has certain advantages in rule coverage comprehensiveness and vulnerability logic expression capability, and is suitable for handling contracts with clear structure and explicit vulnerability patterns, but its detection capability still depends on the completeness of vulnerability patterns, making it difficult to handle complex code paths or logic fuzzy contract scenarios. In the experiment, its F1 scores for all types of vulnerabilities were at a medium level (e.g., 59.00% for integer overflow and 58.80% for delegate call vulnerabilities), showing that the detection effect is highly dependent on the completeness of rules. In addition, sfuzz, as a lightweight dynamic analysis tool based on the idea of fuzz testing, triggers path execution to discover potential vulnerabilities by constructing diverse inputs, but due to the lack of structured guidance in its input generation mechanism and insufficient execution path coverage, its overall performance in the experiment is poor, with F1 scores generally low for all four types of vulnerabilities. For example, the F1 score for reentrancy attack vulnerabilities is only 22.22%, and for delegate call vulnerabilities, it is 54.17%, reflecting the significant limitations of its dynamic mechanism in handling complex logic vulnerabilities that depend on conditions.

[0139] The performance advantage of the vulnerability detection system of the present application is mainly due to its deep fusion modeling capability for program structure and language semantics. The system not only constructs the control flow graph, data flow graph and abstract syntax tree of the contract, but also further extracts the semantic dependency relationship between functions, and inputs these structured information together with the source code into the large language model for unified modeling and semantic reasoning. With the powerful context modeling capability and cross-function understanding capability of the language model, the vulnerability detection system of the present application can identify implicit vulnerability patterns, non-explicit call paths and semantic confusion logic that are difficult to detect by traditional tools. For example, in integer overflow detection, the vulnerability detection system of the present application analyzes variable boundaries and constraint conditions across statements, achieving an F1 score of 96.06%, which is significantly better than traditional methods based on symbolic execution or static rules.

[0140] In summary, the vulnerability detection system of the present application breaks through the limitations of traditional detection tools in rule coverage range, path analysis capability and semantic understanding depth by fusing program graph structure and reasoning capability of large language models, and realizes more accurate and comprehensive vulnerability detection.

[0141] RQ2: Compared with existing advanced large language models, does the vulnerability detection system of the present application have more outstanding performance?

[0142] As shown in Table 2, the vulnerability detection performance of the vulnerability detection system of the present application is compared with that of seven advanced large language models (using large language models to directly detect the smart contract under test) on the same benchmark dataset. The precision, recall and F1 score of four types of vulnerabilities are summarized in Table 2. In order to more intuitively show the comparison of the vulnerability detection effect of each tool on the same dataset, a line chart is drawn according to the data in the table as shown in FIG. 1. Next, the results will be analyzed in detail for different vulnerability types to better show the advantages of the vulnerability detection system of the present application compared with other large language models in smart contract vulnerability detection. Figure 1

[0143] Table 2 Comparison of vulnerability detection performance of the vulnerability detection system of the present application and existing large language models on the same dataset

[0144]

[0145] Comparison of reentrant vulnerability detection results

[0146] ​In the reentrant vulnerability detection task, the vulnerability detection system of the present application shows the best overall detection capability, with a precision of 59.72%, a recall rate of 96.11%, and an F1 score of 73.67%. This shows that the vulnerability detection system of the present application not only can find most of the real reentrant vulnerabilities, but also has strong accuracy and can effectively avoid a large number of false positives. In contrast, although deepseek-reasoner has a higher recall rate (97.31%), its precision is slightly lower, only 52.59%, and its F1 score is 68.28%, indicating that the model tends to "conservative capture" and is more likely to misjudge non-vulnerabilities as vulnerabilities, resulting in a high false positive rate.

[0147] Although other models such as GPT-4o, llama-3.1 and claude-3-opus generally maintain a recall rate of more than 85%, showing certain vulnerability recognition ability, due to the fact that the precision is generally around 30% and the F1 score is less than 45%, it is shown that these models may bring more false positives in actual application, thereby affecting the credibility of the detection results. The occurrence of this phenomenon may be related to the limited ability of the model to understand the context in handling complex function call chains and identifying cross-function recursive call scenarios.

[0148] The reason why the vulnerability detection system of the present application can perform better in this task is that the integrated graph structure analysis mechanism can more accurately identify potential reentrant risks under the enhancement of call graphs and dependency path information, and the vulnerability detection system of the present application introduces structured prompts in the pre-classification and context modeling stage, so that large language models can focus on positions and patterns prone to reentry, thereby achieving a more balanced precision and recall.

[0149] Comparison of timestamp vulnerability detection results

[0150] In the timestamp vulnerability detection, the vulnerability detection system of the present application still shows a leading advantage, with a precision of 66.50%, a recall rate of 91.48%, and an F1 score of 77.02%. This result shows that the vulnerability detection system of the present application can comprehensively identify time-dependent logical defects while maintaining relatively high accuracy. This is particularly important for contract types that use block timestamps as a basis for logical judgment, as such vulnerabilities often involve uncertainty and misuse of external variables outside the blockchain system.

[0151] Although Grok-3 has a recall rate of 99.47%, which is the highest among all models, its precision is 51.44% and its F1 score is 67.81%, indicating that the model tends to overgeneralize and is more likely to misjudge ordinary time-related logic as vulnerability logic. The performance of models such as GPT-4o and llama-3.1 is more mediocre and has not been able to achieve breakthroughs in both precision and recall.

[0152] The reason for this difference may be that different tools have different understandings of the blockchain-specific context, such as the specific use of "block.timestamp" or "now". The vulnerability detection system of the present application can more accurately capture the semantic scene of timestamp use by combining the auxiliary results of static analysis tools and the context vectors generated by graph neural networks, thereby improving the overall detection performance.

[0153] Integer overflow vulnerability detection results comparison

[0154] In terms of integer overflow vulnerability detection, the vulnerability detection system of the present application performs almost perfectly, with a precision rate of 97.90%, a recall rate of 94.29%, and an F1 score of 96.06%. This indicates that the system not only can find almost all integer overflow vulnerabilities, but also can greatly reduce the false positive rate, showing excellent stability and practicality.

[0155] deepseek-reasoner also performs very well in this detection, slightly inferior to the vulnerability detection system of the present application. Models such as qwen-plus and claud-3-opus perform well, but GPT-4o and llama-3.1 have weaker detection capabilities, with F1 scores of 21.08% and 48.57% respectively, indicating that they have obvious shortcomings in handling low-level variable operations and overflow boundary judgments.

[0156] The fundamental reason for this gap may be that integer overflow detection relies on the understanding of variable assignment statements, arithmetic operation boundaries (such as uint256 upper limit), and symbolic range derivation, etc. Traditional large language models are prone to misjudgment without explicit arithmetic constraint modeling capabilities. The vulnerability detection system of the present application improves its detection accuracy and recall ability by introducing the feature information of arithmetic operation nodes in the abstract syntax tree and fusing the overflow risk scores of static analysis to guide the system to focus on analyzing statements with boundary operations.

[0157] Comparison of results of proxy call vulnerability detection

[0158] In the detection of external call vulnerabilities of the proxy call type, the vulnerability detection system of the present application has the highest F1 score (74.88%) with a precision rate of 60.90% and a recall rate of 97.19%. This type of vulnerability often occurs in complex cross-contract scenarios due to its dependence on contract execution context and storage permission transfer, making it relatively more difficult to detect. The excellent performance of the vulnerability detection system of the present application in this task indicates that it has stronger understanding and discrimination ability in complex cross-contract semantic tracking.

[0159] GPT-4o and Grok-3 followed closely behind, ranking second and third with F1 scores of 70.65% and 69.71% respectively, indicating that these models have certain capabilities in handling delegated call vulnerability detection. However, deepseek-reasoner performed poorly, with an F1 score of only 8.97%, almost unable to effectively detect such vulnerabilities, possibly because it lacks modeling in handling contract context switching and permission binding mechanisms.

[0160] The advantage of the vulnerability detection system of the present application lies in the use of a graph structure enhancement module, which can identify the location of the delegated call and whether there is a dangerous context switch or user-controllable path. In addition, a dependency path attention mechanism is also used, which significantly enhances the sensitivity to "caller context changes", thereby more effectively identifying such high-risk vulnerabilities.

[0161] RQ3: What is the impact of the graph structure enhancement mechanism on vulnerability detection performance?

[0162] Through ablation experiments, the specific impact of each key module in the vulnerability detection system of the present application on the overall vulnerability detection performance is further explored. To this end, while keeping other modules unchanged, the three core components are removed: vulnerability classification module, graph structure enhancement module, and questioning mechanism module, and the detection performance of the complete system is compared. Among them, removing the vulnerability classification module represents directly using a unified large language model (deepseek-reasoner) to detect vulnerabilities in contract source code; removing the graph structure enhancement module represents that the smart contract to be detected is directly called after the vulnerability classification module; removing the questioning mechanism module represents that only a single large language model is used for static detection based on classification and graph information, without introducing review feedback and multiple rounds of collaborative correction process. Table 3 lists the evaluation indicators of the four types of common vulnerabilities under these four settings, including precision, recall, and F1 score.

[0163] Table 3 Ablation experiment

[0164]

[0165] Overall, the vulnerability detection system of the present application with complete modules achieved the best F1 score on all types of vulnerabilities, with a reentrant attack vulnerability of 73.67%, a timestamp dependency vulnerability of 77.02%, an integer overflow of 96.06%, and a delegated call vulnerability of 74.88%. This result fully demonstrates that under the joint action of classification guidance, graph structure enhancement, and questioning mechanism modules, the vulnerability detection system of the present application can more comprehensively understand the semantic features of different vulnerabilities, effectively balance the false positive rate and the false negative rate, and maintain high accuracy while achieving high recall, demonstrating strong robustness and generalization ability.

[0166] Further analysis results can find that the removal of the vulnerability classification module has a significant impact on performance, which is stable overall but has obvious degradation. In this setting, the F1 scores of the four types of vulnerabilities all show a certain degree of decline, especially the timestamp-dependent and delegate call vulnerabilities, which decrease to 74.46% and 73.78%, respectively. This shows the important role of the classification module in guiding the selection of subsequent analysis paths. Different types of vulnerabilities in smart contracts often exhibit specific semantic features and code structure patterns, such as reentrancy vulnerabilities involving external calls and state update sequences, and timestamp vulnerabilities focusing on the use of block variables. The classification mechanism can divide contract samples into appropriate sub-tasks in the pre-processing stage, guiding the vulnerability detection system to select more targeted analysis strategies and coding methods. The absence of the classification step will cause different vulnerabilities to be mixed into the detection system, making it difficult to consider the differences in various features, thereby affecting the overall judgment and sensitivity of the system.

[0167] Secondly, the removal of the graph structure enhancement module has the most significant performance degradation, reflecting the key supporting role of structural information in vulnerability detection. In this setting, the F1 score has the highest decline among all configurations, with reentrancy attack vulnerabilities decreasing from 73.67% to 65.37% and delegate call vulnerabilities decreasing from 74.88% to 66.67%. This phenomenon reveals the irreplaceability of the structure enhancement module in semantic modeling. By introducing intermediate representations such as control flow graphs, data flow graphs, and abstract syntax trees, the vulnerability detection system not only obtains static context information such as variable dependencies and function call chains, but also reveals behavioral features such as attack paths, conditional dependencies, and state transitions from a structural perspective. This is particularly important for vulnerabilities such as reentrancy attacks and delegate calls, which rely on cross-function and cross-module behavior paths. The absence of graph structures makes the system rely solely on linear source code text for judgment, significantly reducing its ability to capture complex control logic and dependency relationships, resulting in a double decline in recall and precision.

[0168] In addition, the removal of the questioning mechanism also brings significant performance degradation, especially in the detection of timestamp-dependent vulnerabilities and delegate call vulnerabilities. In this setting, the F1 value of timestamp-dependent vulnerabilities decreases from 77.02% to 69.03%, and delegate call vulnerabilities decrease to 67.30%. This result shows that the questioning mechanism plays an important role in improving the robustness and generalization ability of the vulnerability detection system. In the vulnerability detection system, the designed questioning mechanism analyzes the smart contract from different perspectives, such as static feature attention, context dependency reasoning, and semantic constraint identification, and finally enhances the consistency and credibility of the results by fusing the judgments. This mechanism effectively alleviates the judgment bias or feature missing problem that may occur in single models when dealing with heterogeneous vulnerability scenarios. After removing this mechanism, the system lacks the ability to integrate information from multiple perspectives, making it more prone to misjudgment in semantically ambiguous or contextually complex scenarios, thereby affecting overall performance.

[0169] In summary, the three modules of vulnerability classification, graph structure enhancement and questioning mechanism respectively improve the vulnerability detection ability of the vulnerability detection system from the three dimensions of task division, semantic modeling and strategy fusion, and are indispensable. Among them, the classification module ensures the targeted modeling of the vulnerability detection system of the present application for multiple types of vulnerabilities, the graph structure enhancement module gives the vulnerability detection system of the present application the ability to capture complex dependencies and execution paths, and the questioning mechanism module improves the stability and accuracy of the detection results. The ablation experiment clearly shows that the introduction of the three modules not only improves the single indicator, but also builds a robust and efficient intelligent contract vulnerability detection system as a whole.

Claims

1. A type-aware and graph-enhanced smart contract vulnerability detection method, characterized in that, Comprise: S1: preliminary judgment is carried out to the smart contract to be tested, the possible vulnerability type is identified, and it is divided into predefined vulnerability types; The predefined vulnerability types include: reentrant attack, timestamp dependence, integer overflow and / or delegation call vulnerability; S2: for different types of vulnerabilities, corresponding graph structure extraction operations are performed to construct graph structures suitable for the vulnerability types; All nodes of the graph structure perform unified index coding, and the coding format is [graph type]-[node ID]-[source code location]; At the same time, a node attribute database is established to record the functional attribute characteristics, associated source code segment characteristics and dependency relationship characteristics of each node; Based on the index and node attribute data, the nodes of different graph structures are sequentially associated according to the priority order of the source code location matching degree, the functional dependence matching degree and the semantic vector matching degree, to obtain corresponding source code location association, dependence association and semantic association node types, specifically: For any two nodes of different graph structures, the source code location field in the index is parsed, and the start line number and the end line number are extracted; According to the formula: overlap degree=overlapping line number / total length of two node line number interval, the overlap degree is calculated, and if the overlap degree is greater than the preset overlap degree, the node type is marked as a source code location association node; If the overlap degree is not greater than the preset overlap degree, the functional attribute characteristics are extracted from the node attribute database, and the "operation-operated" role pair is established; Through the calling stack and the data flow chain, the "operation-operated" dependency relationship of the two different graph structure nodes is traced back, the dependence chain is obtained, the functional dependence matching degree is calculated according to the length of the dependence chain, and if the functional dependence matching degree is greater than the preset functional dependence matching degree, the node type is marked as a dependence association node; If the functional dependence matching degree is not greater than the preset functional dependence matching degree, the associated source code segment characteristics of the node are extracted, converted into a vector, and the cosine similarity is calculated and used as the semantic vector matching degree. The type of the node with a cosine similarity greater than the preset similarity is marked as a semantic association node; According to the node type, the nodes are connected to generate a fused semantic graph representation; The fused semantic graph representation is spliced with the source code of the smart contract to be tested and the structured prompt word to generate a spliced prompt word; S3: calling a large language model to perform structured semantic enhancement analysis on the spliced prompt word, and outputting a detection result; S4: the detection result is reviewed by a verification model to generate questioning data and is fed back to the large language model; After the spliced prompt word and the questioning data are fused, the large language model dynamically adjusts the attention weight of each path of the fused data using the attention mechanism, reoutputs the detection result, and executes S4 until no questioning data is generated or the preset round is reached.

2. The method for smart contract vulnerability detection based on type-aware and graph-enhanced, according to claim 1, characterized in that, S2 described that for different types of vulnerabilities, corresponding graph structure extraction operations are performed to construct graph structures suitable for the vulnerability types, specifically: The reentrant attack vulnerability uses the data flow graph and the control flow graph, the timestamp dependence vulnerability uses the contract tree and the abstract syntax tree, the integer overflow vulnerability uses the control flow graph and the abstract syntax tree, and the delegation call vulnerability uses the dependency abstract syntax tree for modeling.

3. The method for smart contract vulnerability detection based on type-aware and graph-enhanced, according to claim 1, characterized in that, According to the node type, the nodes are connected, specifically: For source code location association nodes, mutual reference edges are established between the two nodes; For dependency association nodes, according to the dependency direction, follow the "dependency source→dependency target" rule to establish a one-way edge; For semantic association nodes, from the nodes with clear semantics to the semantic related nodes, establish a one-way "semantic mapping" edge.

4. The method for smart contract vulnerability detection based on type-aware and graph-enhanced, according to claim 1, characterized in that, The function attribute feature of S2 is function definition, variable assignment, conditional judgment, external call, inheritance declaration; The associated source code segment feature is function signature, variable name, operator, conditional expression, and call parameter; The dependency relationship feature is function call, variable influence, trigger event, parameter dependency, and inheritance dependency.

5. The method for smart contract vulnerability detection based on type-aware and graph-enhanced, according to claim 1, characterized in that, S3 calls the large language model to perform structured semantic enhancement analysis on the spliced prompt words, specifically: If the vulnerability type is a reentrant attack or an integer overflow vulnerability, the deepseek-reasoner large language model is called; If the vulnerability type is a timestamp dependency vulnerability, the Grok-3 large language model is called; If the vulnerability type is a delegate call vulnerability, the GPT-4o large language model is called.

6. The method for smart contract vulnerability detection based on type-aware and graph-enhanced, according to claim 1, characterized in that, S1 identifies possible vulnerability types by using a type-aware model to identify potential vulnerabilities in the contract based on semantic understanding of the contract. The type-aware model is trained and fine-tuned by LoRA using a training data set containing [source code location, vulnerability type, semantic interpretation text] triplets.

7. The method for smart contract vulnerability detection based on type-aware and graph-enhanced, according to claim 1, characterized in that, The detection result of S3 includes: vulnerability detection type, vulnerability location, triggered logic path, and explanatory text.

8. A type-aware and graph-enhanced based smart contract vulnerability detection system, characterized in that, It includes: Vulnerability classification module: preliminarily judges the smart contract under test, identifies possible vulnerability types, and classifies them into predefined vulnerability types; Predefined vulnerability types include: reentrant attack, timestamp dependency, integer overflow, and / or delegate call vulnerability; Graph structure enhancement module: for different types of vulnerabilities, perform corresponding graph structure extraction operations to construct graph structures suitable for the vulnerability types; All nodes of the graph structure perform unified index encoding, and the encoding format is [graph type]-[node ID]-[source code location]; At the same time, a node attribute database is established to record the function attribute feature, associated source code segment feature, and dependency relationship feature of each node; Based on the index and node attribute data, the nodes of different graph structures are associated in order of source code location matching degree, functional dependency matching degree, and semantic vector matching degree priority, to obtain corresponding source code location association, dependency association, and semantic association node types, specifically: For any two nodes of different graph structures, parse the source code location field in the index to extract the start line number and end line number; According to the formula: overlap degree=overlapping lines / total length of two node line number intervals, calculate the overlap degree, if the overlap degree is greater than the preset overlap degree, the node type is marked as a source code location association node; If the overlap degree is not greater than the preset overlap degree, the functional attribute features are extracted from the node attribute database, and the "operator-operated" role pair is established; the "operator-operated" dependency relationship of two different graph structure nodes is traced back in reverse through the call stack and the data flow chain, the dependency chain is obtained, the functional dependency matching degree is calculated according to the length of the dependency chain, and if the functional dependency matching degree is greater than the preset functional dependency matching degree, the node type is marked as a dependency association node; If the functional dependency matching degree is not greater than the preset functional dependency matching degree, the associated source code segment features of the node are extracted, the cosine similarity is calculated after being converted into a vector, and the cosine similarity is used as the semantic vector matching degree, and the type of the node with a cosine similarity greater than the preset similarity is marked as a semantic association node; According to the node type, the nodes are connected to generate a fused semantic graph representation; The fused semantic graph representation is spliced with the to-be-tested smart contract source code and the structured prompt word to generate a spliced prompt word; The detection result output module: calling a large language model to perform structured semantic enhancement analysis on the spliced prompt word and outputting a detection result; The questioning mechanism module: the detection result is reviewed by a verification model, questioning data is generated, and the questioning data is fed back to the large language model; After the spliced prompt word and the questioning data are fused, the large language model dynamically adjusts the attention weight of each path of the fused data by using an attention mechanism, re-outputs the detection result, enters the questioning mechanism module, and continues until no questioning data is generated or a preset round is reached.

Images