Intelligent contract logic vulnerability detection method and system based on thinking enhancement large model

Abstract

The invention discloses an intelligent contract logic vulnerability detection method and system based on a thinking enhancement large model, and the method comprises the steps: converting a complete intelligent contract project source code into a structured context which is easy to understand and analyze of the large model, and achieving the preprocessing of the intelligent contract project source code; a thinking knowledge base is extracted through a real world security audit report and is used for generating subsequent vulnerability detection thinking; multiple types of agents are designed for collaborative detection, a focus context mechanism is supplemented, multiple processes researched by a security officer are simulated, and vulnerability detection is carried out in an iteration mode.

Description

Technical Field

[0001] This invention relates to the field of smart contract vulnerability detection, specifically to a method and system for detecting smart contract logic vulnerabilities based on a large-scale thinking enhancement model. Background Technology

[0002] Blockchain technology has been widely applied in various industries, including commerce and finance. Smart contracts, as its core pillar, manage massive amounts of on-chain assets in areas such as decentralized finance (DeFi). However, once deployed, the code of a smart contract cannot be altered. If exploitable vulnerabilities exist, they could lead to irreparable and significant economic losses, posing a serious threat to the security of the entire ecosystem.

[0003] To address this risk, the industry has adopted various technical methods for security detection. Traditional techniques, such as static and dynamic analysis, typically rely on pre-defined heuristic rules to scan code. These methods can effectively identify some common vulnerabilities similar to those in traditional software (such as integer overflows and reentrancy attacks). However, the more dangerous and insidious vulnerabilities in smart contracts are often functional logic vulnerabilities closely related to the project's unique business logic. Because these vulnerabilities heavily depend on a deep understanding of the business intent implemented by the code, traditional rule-based techniques are difficult to detect effectively. Therefore, the industry has begun to apply Large Language Models (LLMs), which possess strong code understanding capabilities, to this area. However, practice shows that general-purpose LLMs still have fundamental limitations when facing such problems: while they can parse the syntax and general semantics of code, they lack a deep understanding of the high-level business logic of specific contracts. Therefore, when identifying functional vulnerabilities that require consideration of the business context, they suffer from high false negative and false positive rates, and their detection capabilities do not yet meet financial-grade security requirements.

[0004] Therefore, the industry urgently needs a more accurate and reliable automated vulnerability detection method and system that can combine the code analysis capabilities of large language models with a deep understanding of the specific business logic of smart contracts. This is of vital importance to ensuring the security of blockchain assets. Summary of the Invention

[0005] This invention provides a method and system for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model. This method and system can improve the comprehensiveness, accuracy, and reasoning analysis capabilities of the large-scale model during vulnerability detection, thereby achieving efficient and accurate detection of logical vulnerabilities in smart contracts.

[0006] To achieve the above-mentioned objectives, the present invention provides the following technical solution:

[0007] A method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model, comprising the following steps:

[0008] Step 1: Preprocess the source code of a smart contract project by transforming it into a structured context that is easy for large models to understand and analyze.

[0009] Step 2: Extract a knowledge base of thinking from real-world security audit reports to generate thinking for subsequent vulnerability detection;

[0010] Step 3: By designing collaborative detection involving multiple types of intelligent agents, including developers, researchers, and verifiers, and supplementing it with a focus context mechanism, the system simulates multiple processes of security researchers and performs vulnerability detection in an iterative manner.

[0011] Furthermore, step one specifically includes the following sub-steps:

[0012] S1.1: Scan all Solidity files in the smart contract project, and perform contract-level scanning and parsing on all Solidity files to identify all contract and library code;

[0013] S1.2: Traverse the contract and library code, and use the Solidity Abstract Syntax Tree parsing tool based on the parser to identify the state variables and function bodies in the contract and library code; at the same time, use the Solidity Abstract Syntax Tree parsing tool based on the parser to parse all the import statements of Solidity files, and recursively parse the variable types in the contract and library, and parse the alias types to the actual types;

[0014] The Solidity Abstract Syntax Tree Parsing and Processing Tool, which is based on an improved parser, is obtained as follows: recursive parsing of alias types is added to the import statement parsing callback function of the Solidity Abstract Syntax Tree Parsing and Processing Tool; in the error handling logic of the callback function, the logic of skipping parsing for unparsable requests is changed from aborting parsing to skipping parsing.

[0015] S1.3: Recursively parse the function body to generate the function signature, function name, modifiers, function return type, and statement information within the function;

[0016] S1.4: Perform structured processing on the information parsed from S1.1 to S1.3;

[0017] S1.5: Identify functions in contract and library code by comparing function signatures and AST structures, and exclude audited and widely used standard library and protocol implementations;

[0018] S1.6: Use a code embedding model to vectorize each filtered function in the project, and build a vector database that supports semantic search and can achieve long-term memory.

[0019] Furthermore, the vector database includes a structured codebase context, which includes function signatures, associated contracts, and contract inheritance relationships.

[0020] Furthermore, step two specifically includes the following sub-steps:

[0021] S2.1: By collecting a large number of real-world contract project audit reports from multiple information sources, a large model is used to generate vulnerability thinking templates extracted from each report;

[0022] S2.2: Using the prompts generated from the samples, the vulnerability thinking patterns in the vulnerability thinking template generated in S2.1 are divided into target-oriented thinking and invariant thinking using the large model; wherein, the target-oriented thinking is for a specific vulnerability type, while the invariant thinking is for the specific business logic of the contract.

[0023] Furthermore, the goal-oriented thinking includes the type of smart contract in which the goal-oriented thinking is located, as well as the questions that the intelligent agent needs to answer and the specific steps of the thinking.

[0024] The invariant thinking includes guided thinking steps, which are provided to subsequent developer agents to fill in specific type variables in the thinking steps to generate the instantiated vulnerability detection thinking.

[0025] Furthermore, step three specifically includes the following sub-steps:

[0026] S3.1: The structured context obtained in step one is further transformed into code context through the developer agent. That is, the core functions of the smart contract project and the calling context of these core functions are extracted through the developer agent as a semantic awareness tool layer.

[0027] S3.2: Search for the vulnerability thinking pattern that best matches the current smart contract type from the vulnerability thinking template through the reasoning model, and then concretize this pattern into a specific vulnerability detection thinking that adapts to the current code context;

[0028] S3.3: Using two researcher agents, the specific vulnerability detection thinking generated in S3.2 is utilized, along with the core functions and function contexts of the smart contract project generated in S3.1, to perform function-level vulnerability detection; at the same time, multi-granularity focus context information is summarized for the function context.

[0029] S3.4: Two researcher agents cross-validate and critique each other's detection results through dialogue, and output their detection results after one round of cross-dialogue critique;

[0030] S3.5: The verifier agent verifies the detection results generated from S3.4 according to a predefined checklist. If any vulnerability detection result does not conform to the rules of the checklist, the detection result is discarded.

[0031] Furthermore, the focus context includes function modifiers, function internal call information, contract state variables, and contract inheritance relationships.

[0032] Furthermore, the detection results output by the researcher's intelligent agent contain original abstract thinking, vulnerability types, and reasoning processes.

[0033] Furthermore, the contents of the predefined checklist are as follows:

[0034] (1) Whether each reasoning proof is factually accurate and self-contradictory;

[0035] (2) Whether each reasoning proof is logically related to the final decision;

[0036] (3) Have vulnerabilities based on the behavior of malicious miners / block builders been ruled out?

[0037] (4) Whether each reasoning proof is directly related to the identified vulnerability;

[0038] (5) Does each inference proof avoid assumptions that exceed the given information?

[0039] (6) Are all analyses strictly limited to the given code and without external assumptions?

[0040] A smart contract logic vulnerability detection system based on a large-scale thinking enhancement model includes the following modules:

[0041] The project input module is used to input and read the project code of the smart contract to be analyzed;

[0042] Project Structured Preprocessing Module: This module is used to perform abstract syntax tree parsing on Solidity source files in the project and extract context information at the function level.

[0043] Vulnerability Detection Mindset Instantiation Module: This module is used to search for the vulnerability mindset pattern that best matches the current smart contract project type from the vulnerability mindset template;

[0044] Developer Agent Module: This module is used to convert the structured preprocessing results obtained by the project structured preprocessing module into semantically searchable contextual information through word embedding;

[0045] Function utility call module: This module is used to support other smart agents in semantic understanding and information retrieval of smart contract projects;

[0046] Researcher Agent Module: This module is used to perform specific reasoning and detection on the instantiated vulnerability detection logic, and output the vulnerability detection results after iterative critical analysis.

[0047] Verifier agent module: This module verifies the detection results of the researcher agent according to a predefined checklist, and removes false positive results caused by defects such as hallucinations in the large model by verifying the reasoning process.

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

[0049] 1. The large-scale vulnerability detection method and system based on enhanced thinking proposed in this invention does not rely on traditional static detection rules, has good code semantic understanding ability, and can adapt to various smart contract security detection scenarios such as closed-source contracts and off-chain contracts, thus solving the problem of difficult detection of smart contract logic vulnerabilities.

[0050] 2. This invention provides fine-grained code preprocessing and focus context technology, which can effectively filter the core code logic in smart contracts, enabling large models to focus their limited attention on the most critical code segments, thereby improving the utilization rate and inference efficiency of large model contexts and reducing false positives.

[0051] 3. This invention proposes to enhance the recall and accuracy of large-scale vulnerability detection by using vulnerability thinking templates. It innovatively utilizes large-scale models to extract and summarize historical security audit reports, generating a large number of high-quality vulnerability patterns and higher-order thinking methods. This improves the knowledge background and reasoning ability of large-scale models in vulnerability detection, and can effectively enhance the comprehensiveness, effectiveness and accuracy of vulnerability detection.

[0052] 4. This invention presents a large model optimization technique for multi-agent collaboration. By utilizing the characteristics of different large models (inference models and non-inference models) to divide and collaborate on different sub-tasks, it can effectively overcome the performance bottleneck of large models when processing long code. Furthermore, by combining the advantages of inference models in vulnerability thinking with the advantages of non-inference models in code understanding in terms of accuracy and convergence, the vulnerability detection process is broken down into multi-stage sub-tasks, which are then handled by different agents in collaboration, thereby improving the accuracy and reliability of large models in detection inference. Attached Figure Description

[0053] Figure 1 This is a flowchart of a smart contract logic vulnerability detection method based on a large-scale thinking enhancement model, according to an embodiment of the present invention.

[0054] Figure 2 This is a schematic diagram of a smart contract logic vulnerability detection system based on a large-scale thinking enhancement model, according to an embodiment of the present invention. Detailed Implementation

[0055] The present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments. The purpose and effects of the present invention will become clearer. It should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0056] The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model, as described in this embodiment of the invention, has the following specific process: Figure 1 As shown, it includes the following steps:

[0057] Step 1: Preprocess the source code of a smart contract project by transforming it into a structured context that is easy for a large model to understand and analyze.

[0058] Step one specifically includes the following sub-steps:

[0059] S1.1: Scan all Solidity files in the smart contract project, and perform contract-level scanning and parsing on all Solidity files to identify all contract and library code.

[0060] S1.2: Traverse the contract and library code, and use the Solidity Abstract Syntax Tree (AST) parsing tool, which is an improvement on ANTLR (Another Tool for Language Recognition), to identify state variables and function bodies in the contract and library code. This avoids the dependency on compiling the complete project, enabling it to handle contract code with incomplete dependencies. At the same time, use the Solidity AST parsing tool, which is an improvement on ANTLR, to parse all import statements in Solidity files, and recursively parse the variable types in the contract and library, resolving alias types to actual types.

[0061] Specifically, the Solidity Abstract Syntax Tree Parsing and Processing Tool based on ANTLR is improved by adding recursive parsing of alias types to the import statement parsing callback function of the Solidity Abstract Syntax Tree Parsing and Processing Tool; and modifying the logic of skipping parsing for requests that cannot be parsed from the previous logic of aborting parsing in the error handling logic of the callback function, thus obtaining the Solidity Abstract Syntax Tree Parsing and Processing Tool based on ANTLR.

[0062] S1.3: Recursively parse the function body to generate the function signature, function name, modifiers, function return type, and statement information within the function.

[0063] S1.4: Perform structured processing on the information parsed from S1.1 to S1.3.

[0064] This step uses a Solidity abstract syntax tree parsing tool based on ANTLR, making the parsing process fault-tolerant. It allows skipping the current sub-code at the current level after identifying an erroneous code structure, and proceeding to parse the next sub-code at the current level. This enables adaptive parsing of contracts with missing dependencies or different compilation versions, improving the robustness of the parsing and the project's support capabilities.

[0065] S1.5: By comparing function signatures and AST structures, functions in contract and library code are identified, and audited and widely used standard libraries (such as OpenZeppelin) and protocol implementations (such as Uniswap and AAVE) are excluded, reducing analysis noise and the amount of code in the large input model. This allows for more efficient use of the large model's inference context and improves analysis accuracy.

[0066] It should be noted that the selection of the OpenZeppelin standard library involved analysis of multiple stable versions. Since different contracts use different version numbers of the standard library, adding support for standard library functions from different major versions improves the ability to match and filter standard functions. Furthermore, in fine-grained function implementation comparisons, AST structure comparison was used, which effectively avoids issues caused by changes in code format, variable names, or function names that prevent the identification of standard function implementations.

[0067] S1.6: Vectorize each filtered function in the project using a code embedding model (such as CodeBERT) to build a vector database that supports semantic search and long-term memory. This vector database includes a refined, structured codebase context (including function signatures, associated contracts, contract inheritance relationships, etc.) for subsequent semantic retrieval.

[0068] Step Two: Extract a knowledge base from real-world security audit reports to generate strategies for subsequent vulnerability detection. Step Two includes the following sub-steps:

[0069] S2.1: By collecting a large number of real-world contract project audit reports from multiple information sources, a large model is used to generate a buffer of vulnerability reasoning thoughts extracted from each report, providing a high-level "mind map" for vulnerability detection.

[0070] It should be noted that in this embodiment, the collected audit reports are all specific vulnerability reports of high and medium risk, totaling over 14,000. The real-world contract project audit reports include a description of the vulnerability, its type, severity level, verification code, and the specific location of the vulnerability code. A non-reasoning model is used to extract vulnerability thinking buffers from each vulnerability report.

[0071] S2.2: Based on the prompts generated from the samples, the vulnerability thinking patterns in the vulnerability thinking template generated in S2.1 are divided into "targeted thinking" and "invariant thinking" using the large model. Among them, targeted thinking mainly targets specific vulnerability types, while invariant thinking mainly targets the specific business logic of the contract.

[0072] Specifically, goal-oriented thinking includes the type of smart contract in which the goal-oriented thinking exists (such as Token, Lending, Yield, etc.), the questions that the intelligent agent needs to answer, and the specific steps of the thinking process. Invariant thinking, on the other hand, includes guided thinking steps, and subsequent developer intelligent agents need to fill in the specific type variables in the thinking steps to generate the instantiated vulnerability detection thinking.

[0073] Step 3: By designing collaborative detection involving multiple types of intelligent agents, including developers, researchers, and verifiers, and supplementing it with a "Focal Context" mechanism, the system simulates multiple processes of security researchers, performs vulnerability detection in an iterative manner, and outputs the detection results.

[0074] Step three specifically includes the following sub-steps:

[0075] S3.1: The structured context obtained in step S1.4 is further transformed into code context through the "developer agent". In this step, the core functions of the smart contract project and the calling context of these core functions are extracted through the developer agent, serving as a semantic awareness tool layer to provide basic support for other large models.

[0076] S3.2: Search for the vulnerability thinking pattern that best matches the current smart contract type from the vulnerability thinking template through the reasoning model, and then concretize this pattern into a specific vulnerability detection thinking that adapts to the current code context.

[0077] Specifically, the search process encompasses two main search areas: thought type and thought problem. First, constraints are imposed on both thought modes based on the type of smart contract to be detected. Then, using a code embedding model, the top 30 most similar thought problems are matched from the thought problems. For each thought problem, the specific steps are filled in using a reasoning model combined with the structured context of the smart contract obtained from S1.4, ultimately forming the specific content of the vulnerability detection thought process.

[0078] S3.3: Using two researcher agents, leveraging the specific vulnerability detection strategies generated in S3.2, and utilizing the core functions and function contexts of the smart contract project generated in S3.1, function-level vulnerability detection is performed. Simultaneously, multi-granular focus context information is summarized for the function context, providing concise core function context content and reducing the consumption of large model tokens. Focus context includes function modifiers, function internal call information, contract state variables, and contract inheritance relationships.

[0079] S3.4: Two researcher agents cross-validate and critique each other's detection results through dialogue, and output their detection results after a round of cross-dialogue and critique; the detection results contain the original abstract thinking, vulnerability type, and reasoning process.

[0080] S3.5: The validator agent verifies the detection results generated from S3.4 according to a predefined checklist. If any vulnerability detection result does not conform to the rules of the checklist, the detection result is discarded, thereby eliminating false positive results.

[0081] Specifically, the checklist includes the following:

[0082] (1) Is each reasoning proof factually accurate and free of contradictions? (Check the factual accuracy and internal consistency of the proof process)

[0083] (2) Is there a logical connection between each reasoning proof and the final decision? (Verify the logical coherence between the reasoning chain and the conclusion)

[0084] (3) Have vulnerabilities based on malicious miner / block builder behavior been ruled out? (The analysis should explicitly exclude vulnerabilities based on the assumption of malicious actor behavior.)

[0085] (4) Is each reasoning proof directly related to the identified vulnerability? (Ensure all analysis focuses on the specific vulnerability)

[0086] (5) Does each reasoning proof avoid assumptions beyond the given information? (The arguments are strictly based on known information, without any additional conjecture.)

[0087] (6) Are all analyses strictly limited to the given code and without external assumptions? (Emphasis on code boundary analysis to exclude interference from external factors)

[0088] For each vulnerability detection result, the verifier AI will check the contents of the above checklist one by one. Only if all the contents of the above checklist are met will it be considered as the final vulnerability detection result.

[0089] On the other hand, another embodiment of the present invention also provides a smart contract logic vulnerability detection system based on a large-scale thinking enhancement model, such as... Figure 2 As shown, it specifically includes the following modules:

[0090] Project Input Module: This module is used to input and read the project code of the smart contract to be analyzed.

[0091] Project Structured Preprocessing Module: This module is used to perform abstract syntax tree parsing on Solidity source files in the project and extract context information at the function level.

[0092] Vulnerability Detection Mindset Instantiation Module: This module is used to search for the vulnerability mindset pattern that best matches the current smart contract project type from the vulnerability mindset template.

[0093] Developer Agent Module: This module is used to convert the structured preprocessing results obtained from the project structured preprocessing module into semantically searchable contextual information through word embedding.

[0094] Function tool call module: This module is used to support other smart agents in semantic understanding and information retrieval of smart contract projects.

[0095] Researcher Agent Module: This module is used to perform specific reasoning and detection on the instantiated vulnerability detection logic, and output the vulnerability detection results after iterative critical analysis.

[0096] Verifier Agent Module: This module verifies the detection results of the researcher agent based on a predefined checklist, and removes false positive results caused by defects such as hallucinations in the large model by verifying the reasoning process.

[0097] To further verify the method proposed in this invention, this application experimentally verifies the performance of the method and system by setting up a corresponding experimental environment. The dataset used in this application contains 266 real-world Ethereum smart contract vulnerabilities, and Slither, Ityfuzz, Mythril, and GPTScan are used as baselines for testing. The experimental results are shown in Table 1.

[0098] Table 1. Comparison of test results between the system in this embodiment and four vulnerability detection tools.

[0099] toolset Recall rate accuracy F1 This invention 0.719 0.743 0.731 Slither 0.410 0.099 0.160 Ityfuzz 0.225 0.629 0.331 Mythril 0.421 0.200 0.269 GPTScan 0.108 0.458 0.175

[0100] Experiments show that the present invention achieves an accuracy of 74.3% on real-world vulnerability datasets, which is far higher than existing methods. It also performs well in terms of recall and F1 score, thus proving the effectiveness of the present method.

[0101] It will be understood by those skilled in the art that the above descriptions are merely preferred examples of the invention and are not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art can still modify the technical solutions described in the foregoing examples or make equivalent substitutions for some of the technical features. All modifications and equivalent substitutions made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model, characterized in that, The method includes the following steps: Step 1: Preprocess the source code of a smart contract project by transforming it into a structured context that is easy for large models to understand and analyze. Step 2: Extract a knowledge base of thinking from real-world security audit reports to generate thinking for subsequent vulnerability detection; Step 3: By designing collaborative detection involving multiple types of intelligent agents, including developers, researchers, and verifiers, and supplementing it with a focus context mechanism, the system simulates multiple processes of security researchers, performs vulnerability detection in an iterative manner, and outputs the detection results.

2. The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model according to claim 1, characterized in that, Step one specifically includes the following sub-steps: S1.1: Scan all Solidity files in the smart contract project, and perform contract-level scanning and parsing on all Solidity files to identify all contract and library code; S1.2: Traverse the contract and library code, and use the Solidity Abstract Syntax Tree parsing tool based on the parser to identify the state variables and function bodies in the contract and library code; at the same time, use the Solidity Abstract Syntax Tree parsing tool based on the parser to parse all the import statements of Solidity files, and recursively parse the variable types in the contract and library, and parse the alias types to the actual types; The Solidity Abstract Syntax Tree Parsing and Processing Tool, which is based on an improved parser, is obtained as follows: recursive parsing of alias types is added to the import statement parsing callback function of the Solidity Abstract Syntax Tree Parsing and Processing Tool; in the error handling logic of the callback function, the logic of skipping parsing for unparsable requests is changed from aborting parsing to skipping parsing. S1.3: Recursively parse the function body to generate the function signature, function name, modifiers, function return type, and statement information within the function; S1.4: Perform structured processing on the information parsed from S1.1 to S1.3; S1.5: Identify functions in contract and library code by comparing function signatures and AST structures, and exclude audited and widely used standard library and protocol implementations; S1.6: Use a code embedding model to vectorize each filtered function in the project, and build a vector database that supports semantic search and can achieve long-term memory.

3. The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model according to claim 2, characterized in that, The vector database includes a structured codebase context, which includes function signatures, the contract to which it belongs, and contract inheritance relationships.

4. The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model according to claim 1, characterized in that, Step two specifically includes the following sub-steps: S2.1: By collecting a large number of real-world contract project audit reports from multiple information sources, a large model is used to generate vulnerability thinking templates extracted from each report; S2.2: Using the prompts generated from the samples, the vulnerability thinking patterns in the vulnerability thinking template generated in S2.1 are divided into target-oriented thinking and invariant thinking using the large model; wherein, the target-oriented thinking is for a specific vulnerability type, while the invariant thinking is for the specific business logic of the contract.

5. The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model according to claim 4, characterized in that, The target-oriented thinking includes the type of smart contract in which the target-oriented thinking is located, as well as the questions that the intelligent agent needs to answer and the specific steps of the thinking. The invariant thinking includes guided thinking steps, which are provided to subsequent developer agents to fill in specific type variables in the thinking steps to generate the instantiated vulnerability detection thinking.

6. The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model according to claim 4, characterized in that, Step three specifically includes the following sub-steps: S3.1: The structured context obtained in step one is further transformed into code context through the developer intelligent agent. That is, the core functions of the smart contract project and the calling context of these core functions are extracted through the developer intelligent agent as a semantic awareness tool layer. S3.2: Search for the vulnerability thinking pattern that best matches the current smart contract type from the vulnerability thinking template through the reasoning model, and then concretize this pattern into a specific vulnerability detection thinking that adapts to the current code context; S3.3: Using two researcher agents, the specific vulnerability detection thinking generated in S3.2 is utilized, along with the core functions and function contexts of the smart contract project generated in S3.1, to perform function-level vulnerability detection; at the same time, multi-granularity focus context information is summarized for the function context. S3.4: Two researcher agents cross-validate and critique each other's detection results through dialogue, and output their detection results after one round of cross-dialogue critique; S3.5: The verifier agent verifies the detection results generated from S3.4 according to a predefined checklist. If any vulnerability detection result does not conform to the rules of the checklist, the detection result is discarded.

7. The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model according to claim 6, characterized in that, The focus context includes function modifiers, function call information, contract state variables, and contract inheritance relationships.

8. The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model according to claim 6, characterized in that, The detection results output by the researcher's intelligent agent contain original abstract thinking, vulnerability types, and reasoning processes.

9. The method for detecting logical vulnerabilities in smart contracts based on a large-scale thinking enhancement model according to claim 6, characterized in that, The contents of the predefined checklist are as follows: (1) Whether each reasoning proof is factually accurate and self-contradictory; (2) Whether each reasoning proof is logically related to the final decision; (3) Have vulnerabilities based on the behavior of malicious miners / block builders been ruled out? (4) Whether each reasoning proof is directly related to the identified vulnerability; (5) Does each inference proof avoid assumptions that exceed the given information? (6) Are all analyses strictly limited to the given code and without external assumptions? 10. A smart contract logic vulnerability detection system based on a large-scale thinking enhancement model, characterized in that, Includes the following modules: Project Input Module: This module is used to input and read the project code of the smart contract to be analyzed; Project Structured Preprocessing Module: This module is used to perform abstract syntax tree parsing on Solidity source files in the project and extract context information at the function level. Vulnerability Detection Mindset Instantiation Module: This module is used to search for the vulnerability mindset pattern that best matches the current smart contract project type from the vulnerability mindset template; Developer Agent Module: This module is used to convert the structured preprocessing results obtained by the project structured preprocessing module into semantically searchable contextual information through word embedding; Function utility call module: This module is used to support other smart agents in semantic understanding and information retrieval of smart contract projects; Researcher Agent Module: This module is used to perform specific reasoning and detection on the instantiated vulnerability detection logic, and output the vulnerability detection results after iterative critical analysis. Verifier agent module: This module verifies the detection results of the researcher agent according to a predefined checklist, and removes false positive results caused by defects such as hallucinations in the large model by verifying the reasoning process.

Images