NFT intelligent contract vulnerability detection method based on large language agent

Abstract

The invention discloses an NFT intelligent contract vulnerability detection method based on a large language agent, and relates to an NFT intelligent contract security auditing method integrating expert knowledge, a large language model and static analysis. According to the NFT intelligent contract vulnerability detection method based on the big language intelligent agent, scene attribute characteristics of vulnerabilities are mined based on the ability of the big language intelligent agent, and detection results are filtered for the second time through a program analysis technology, so that intelligence and automation of NFT intelligent contract vulnerability detection are realized, the defects of NFT intelligent contract vulnerability detection methods are overcome, and the generalization ability, efficiency and accuracy of detection are improved; and the support of an external knowledge base is utilized, and the external knowledge base is constructed based on the standard interface document of the smart contract, so that normative and authoritative premise guarantee is formed, rich background knowledge and empirical data are provided for vulnerability detection, and the pertinence and depth of detection are enhanced.

Description

Technical Field

[0001] The present invention belongs to the field of artificial intelligence and software testing, and in particular to an NFT smart contract vulnerability detection method based on a large language intelligent agent. Background Art

[0002] Non-fungible tokens (NFTs) are a representation of digital or physical assets on the blockchain, and their booming development has driven the prosperity of the Web3 ecosystem. NFTs allow developers to use smart contract code running on the blockchain to encode NFT operating rules to achieve the minting, trading and management of NFTs. NFT smart contract code standards such as the ERC-721 standard specify the implementation of basic application program interfaces (APIs) in NFT smart contracts, providing NFTs with basic capabilities such as minting and trading. However, NFT smart contracts are also accompanied by various security issues, namely security issues such as logical vulnerabilities that are common in smart contract codes, which are vulnerable to malicious attacks. Security vulnerability detection for NFT smart contracts can ensure the security and robustness of NFTs, provide security for the NFT ecosystem, and avoid financial losses for NFT holders.

[0003] At present, the security audit tools for NFT smart contracts use symbolic execution methods, which rely on program control flow graphs and execution path solutions. They do not consider the business operation logic of smart contracts, and cannot deal with the path explosion problem in complex smart contracts. In similar research fields, such as the smart contract audit method of cryptocurrency, the fuzzy testing method is limited by the test case generation strategy and generation quality, and its actual detection performance is difficult to control; the vulnerability detection method based on the large language model prompt is affected by the reasoning ability of the large language model itself, and has a high false positive rate, and the accuracy is difficult to guarantee.

[0004] Therefore, how to design an NFT smart contract vulnerability detection method to strike a balance between vulnerability detection efficiency and accuracy to adapt to increasingly complex NFT scenarios and security needs is an important issue that cannot be ignored in the research on NFT smart contract security audits. Summary of the invention

[0005] In view of the shortcomings of the prior art, the present invention provides an NFT smart contract vulnerability detection method based on a large language intelligent agent. The method targets NFT smart contracts, solves problems such as scenario attribute feature generation and verification rule modeling of smart contract security vulnerabilities in NFT scenarios, and outputs detection results for NFT smart contract vulnerabilities.

[0006] The present invention is achieved through the following technical solutions:

[0007] According to a first aspect of an embodiment of the present application, a method for detecting vulnerabilities in an NFT smart contract using a large language model and program analysis is provided, comprising the following steps:

[0008] (1) Code preprocessing: delete blank lines in the code, delete blank lines in comments, and merge line breaks in function definitions

[0009] (2) Code slicing: Combined with the application binary interface (ABI) of the smart contract, retrieve the function set F = {fn} in the code, where fn represents the nth function; perform code slicing on the functions in the function set;

[0010] (3) Build an external knowledge base: Extract the code part ERC721 from the Ethereum official document ERC-721 standard code , including comments; and use the big language tool GPT, enter the code extracted in the previous step in the prompt, and guide GPT to identify all the interfaces and function names that need to be implemented by NFT smart contracts, as well as the corresponding parameter definitions, function function descriptions, function key variable check descriptions, and requirements statement necessity descriptions: GPT (ERC721 C ode)→(Interfaces, Functions, Parameters, Descriptions), where GPT represents the processing by the big language tool GPT, Interfaces represents the interface, Functions represents the function description, Parameters represents the parameter definition, and Descriptions represents the necessity description of the requirements statement; and a structured external knowledge base KB={(Interfaces, Functions, Parameters, Descriptions) is formed. i , Function j , Params k ,Desc l )};

[0011] (4) Generate prompts based on the knowledge base: Generate prompt words for the large model detection phase and prompt words for the program analysis verification phase;

[0012] (5) Large model detection: Write GPT prompt words based on the idea of ​​the thought chain model; get the large model detection results of the code snippet for four vulnerabilities: Results GPT Represents the detection results of the large model for four vulnerabilities. Represents a code snippet, Vul j Represents vulnerability j, Judgment k Represents "yes" or "no";

[0013] (6) Program analysis verification: Further judgment is made on the large model detection results in step (5). First, the respective conditions are proposed for the missing Requirements statement vulnerability, ERC721 reentry vulnerability, infinite casting vulnerability and public burning vulnerability to be detected, and finally the NFT smart contract vulnerability detection results are output; if there are vulnerabilities after large model detection and program analysis verification, it is considered that the contract has a vulnerability.

[0014] Furthermore, in step (2), code slicing is performed on the functions in the function set, specifically including the following sub-steps:

[0015] (2.1) Traverse each unsliced ​​function in the function set F, analyze the relevant nodes in the abstract syntax tree AST of the function, and construct a function call relationship graph, denoted as CallGraph(f);

[0016] (2.2) Check each node in the function call graph. If the current node is a sliced ​​function, add the function to be sliced ​​and other functions with slices in the graph to the slice of the current node. For the remaining sliced ​​functions in the call graph, merge the slices.

[0017] (2.3) Check the code slices and check the external variables read or written by each function in the function sequence to form a read state variable set S read ={S r1 ,S r2 ,...,S rn} and the state variable set S written read ={S r1 ,S r2 ,...,S rn}.

[0018] Specifically, the function set in step (2.1) does not include declaration statements of public libraries or private libraries, does not include abstract functions, and does not include declaration statements of interface class functions.

[0019] Furthermore, the slicing function in step (2.2) is specifically a mapping relationship M slice ={(id,(E seq , S))}, the key in this mapping is the slice id, and its value (F seq ,S) is a combination, where E seq =[f1, f2, ..., f k ] is a sequence of functions in a function call graph starting from a public function as the entry point, and S = {s1, s2, ..., s m}The key variable set is a set of external state variables read or written by each function in the function sequence.

[0020] Furthermore, in step (4), the large model detection phase prompt words are generated, specifically: scenario attribute prompt words T are generated for four NFT smart contract vulnerabilities vuln ={T reentrant , T requirements , T infinite , T burn}; The four NFT smart contract vulnerabilities are ERC721 reentry, missing Requirements statement, unlimited casting and public burning; Use the prompt word template to form the scenario attribute prompt word "Given the following vulnerability materials, you should summarize the vulnerability 'scenario' and 'attribute' of [% vulnerability name%] in the NFT smart contract, where 'scenario' describes the code function where the vulnerability may occur, and 'attribute' explains the code attribute or operation of the vulnerability; control the length of 'scenario' and 'attribute' within one sentence respectively, and answer in json format: {scenario:[%SCENARIO%], property:[%PROPERTY%]}"; Then input the prompt word into GPT to get the scenario attribute information about the four vulnerabilities: SP vul ={scenrio vul ,property vul}, where scenario vul Represents the scenario information of the vulnerability vul, property vul Represents the attribute information of the vulnerability vul.

[0021] Furthermore, the program analysis method verification phase prompt word in step (4) includes the following sub-steps:

[0022] (4.1) For the missing Requirements statement vulnerability, use the interface, function, parameter and description information in the knowledge base KB to generate prompt words for finding key variables;

[0023] (4.2) Input the prompt word into GPT to obtain the standard interfaces defined in the ERC721 standard, the function signatures, variable lists, function call relationships, comparison relationships, descriptions and other information corresponding to each standard interface.

[0024] Furthermore, the step (5) of writing the GPT prompt words according to the idea of ​​the thought chain model includes the following sub-steps:

[0025] (5.1) First, the system background is specified: "You are a smart contract auditor, and you will be asked questions about the properties of the code; in addition, please strictly follow the output format; you do not need to explain your answers";

[0026] (5.2) Perform scene matching and write scene matching prompt words, with the prompt words attached with the function fragments formed in the slice, and then guide GPT to output the true and false judgments for the four candidate vulnerability scenarios respectively;

[0027] (5.3) Use the prompt words in the attribute matching stage to select the vulnerability scenario that is output as "yes" in the previous step, and add the description of the specified attribute in the prompt words: "Does this smart contract code conform to '[%SCENARIO,;PROPERTY%]'? Please answer 'yes' or 'no'"; if GPT answers "yes", it will be added as a candidate.

[0028] Furthermore, in step (6), respective conditions are proposed for detection of missing Requirements statement vulnerability, ERC721 reentrancy vulnerability, infinite casting vulnerability and public burning vulnerability, specifically:

[0029] (6.1) The following conditions are specified for the missing requirements statement vulnerability: Condition ① (P1): Check whether all state variables proposed in the comment exist in at least one requirement statement. S represents the set of state variables s in the comment, and R represents the set of requirements statements r. Define S r is the set of state variables mentioned in r; Condition ② (P2): Extract the binary comparison relations in the comments. For each comparison relation, check whether there is at least one requirement statement that satisfies the implementation of the comparison relation. C represents the set of all binary comparison relations in the comments. If any of the two conditions is not met, the contract is considered to have a missing Requirements statement vulnerability:

[0030] P1

[0031] P2:

[0032]

[0033] (6.2) Secondly, regarding the ERC721 reentrancy vulnerability: Condition ① (P1): The function is not an interface in the openzeppelin framework, but is written independently; Condition ② (P2): The function itself can be called externally, or other functions in the contract that can be called externally can change a state variable in this function; Condition ③ (P3): The internal call of the function includes the onERC721Received function; Condition ④ (P4): After the onERC721Received call, a write operation is performed on a "read before call" state variable; If all four conditions are met, it is considered that the contract has an ERC721 reentrancy vulnerability; its expression is as follows:

[0034] P1

[0035] P2

[0036] P3

[0037] P4:

[0038]

[0039] (6.3) Then, for the infinite casting vulnerability: Condition ① (P1): There is a read operation on the supply related variables in the mint function; Condition ② (P2): The related variables are not compared with the rarity parameters; If either of the two conditions is not met, it is considered that the contract has an infinite casting vulnerability; its expression is as follows:

[0040] Pl

[0041] P2

[0042]

[0043] (6.4) Finally, for the public burning vulnerability: Condition ① (P1): There is no burn function or the visibility of the burn function is not public (publicly visible) Condition ② (P2): The burn function needs to check whether the caller is the NFT owner; if either of the two conditions is not met, the contract is considered to have a public burning vulnerability; its expression is as follows:

[0044] Pl

[0045] P2:checkOwner(f burn ,caller(f));

[0046]

[0047] After the above steps, the NFT smart contract vulnerability detection results can be output; if there are vulnerabilities after large model detection and program analysis verification, the contract is considered to have vulnerabilities.

[0048] According to a second aspect of an embodiment of the present application, there is provided an electronic device, including: one or more processors;

[0049] A memory for storing one or more programs;

[0050] When the one or more programs are executed by the one or more processors, the one or more processors implement the NFT smart contract vulnerability detection method based on large language agent.

[0051] According to a third aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the NFT smart contract vulnerability detection method based on a large language agent are implemented.

[0052] The beneficial effects of the present invention are as follows:

[0053] The present invention integrates large language agents and program analysis technology, and can mine the "scenario attribute" characteristics of vulnerabilities based on the ability of large language agents, and then filter the detection results through program analysis technology to achieve intelligent and automated detection of NFT smart contract vulnerabilities. Compared with traditional methods, it fills the methodological deficiencies in NFT smart contract vulnerability detection and improves the generalization ability, efficiency and accuracy of detection. In addition, the present invention utilizes the support of external knowledge bases and builds external knowledge bases based on the standard interface documents of smart contracts, which constitutes a normative and authoritative premise guarantee, and provides rich background knowledge and experience data for vulnerability detection, enhancing the pertinence and depth of detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0055] Figure 1 It is a flow chart of the NFT smart contract vulnerability detection method based on large language intelligent agent of the present invention. DETAILED DESCRIPTION

[0056] Here, exemplary embodiments are described in detail, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application.

[0057] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0058] The present invention will be further described below by way of embodiments in conjunction with the accompanying drawings, but the scope of the present invention is not limited in any way.

[0059] like Figure 1 As shown in the figure, a process of NFT smart contract vulnerability detection method based on large language agent is implemented in six stages:

[0060] Phase 1: Code preprocessing

[0061] Phase 2: Code Slicing Phase

[0062] Phase 3: Building an external knowledge base

[0063] Stage 4: Generate prompts based on knowledge base

[0064] Stage 5: Large Model Detection Stage

[0065] Phase 6: Program Analysis Method Verification Phase

[0066] The first stage includes the following steps:

[0067] (1.1) Delete blank lines in code and comments

[0068] (1.2) Merge line breaks in function definitions

[0069] The second stage includes the following steps:

[0070] (2.1) In combination with the application binary interface (ABI) of the smart contract, the function set F = {fn} in the search code is retrieved, where fn represents the nth function. The function set does not include declaration statements of public libraries and private libraries, abstract functions, or interface class function declaration statements.

[0071] (2.2) Code slicing is performed for functions in the function set. The essence of slicing is a mapping relationship M slice ={(id,(F seq , S))}. The key is the slice id, and the value is the corresponding function sequence F seq =[f1, f2, ..., f k ] is a sequence of functions in a function call graph starting from a public function as the entry point, and a key variable set S = {s1, s2, ..., s m} A set of external state variables read or written by each function in the function sequence. The step 2.2 includes the following sub-steps, as follows:

[0072] (2.2.1) Traverse each unsliced ​​function in the set F, analyze the relevant nodes in the abstract syntax tree (AST) of the function, and construct a function call relationship graph, denoted as CallGraph(f).

[0073] (2.2.2) Check each node in the function call graph. If the current node is a sliced ​​function, add the function to be sliced ​​and other sliced ​​functions in the graph to the slice of the current node. For the remaining sliced ​​functions in the call graph, merge the slices.

[0074] (2.2.3) Check the code slices and check the external variables read or written by each function in the function sequence to form a read state variable set S read ={S r1 ,S r2 ,...,S rn} and the state variable set S written read ={S r1 ,S r2 ,...,S rn}.

[0075] The third stage includes the following steps:

[0076] (3.1) Extract the code part ERC721 from the Ethereum official document ERC-721 standard code , including comments

[0077] (3.2) Use the big language tool GPT. In the prompt, enter the code extracted in the previous step and guide GPT to identify the interfaces and function names that all NFT smart contracts need to implement, as well as the corresponding parameter definitions, function function descriptions, function key variable check descriptions, and requirements statement necessity descriptions

[0078] GPT(ERC721 C ode)→(Interfaces, Functions, Parameters, Descriptions);

[0079] (3.3) Forming structured external knowledge:

[0080] KB={(Interface i , Function j , Params k ,Desc l )}.

[0081] The fourth stage includes the following steps:

[0082] (4.1) Generate prompt words for the large model detection phase: Generate scenario attribute prompt words T for four NFT smart contract vulnerabilities (ERC721 reentry, missing Requirements statement, unlimited casting, public burning) vuln ={T reentrant , T requirements , T infinite , T burn Use the prompt word template to form the scenario attribute prompt word "Given the following vulnerability materials, you should summarize the vulnerability 'scenario' and 'attribute' of [% vulnerability name%] in the NFT smart contract, where 'scenario' describes the code function where the vulnerability may occur, and 'attribute' explains the code attribute or operation of the vulnerability. Please limit the length of 'scenario' and 'attribute' to one sentence respectively. And the answer complies with the json format: {scenario:[%SCENARIO%],property:[%PROPERTY%]}". Then, input the prompt word into GPT to obtain the scenario attribute information about the four vulnerabilities. SP vul ={scenrio vul ,property vul}.

[0083] (4.2) Generate prompt words for the program analysis method verification phase, the step 4.2 specifically includes the following sub-steps:

[0084] (4.2.1) Mainly for the missing Requirements statement vulnerability: Use the interface, function, parameter and description information in the knowledge base KB to generate the following prompt words for finding key variables: "Read the ERC721 specification below and extract the throw statement description of each function annotation to be implemented in `@dev`. Then extract the specific requirements that appear in the requirement status description point by point, for example. You need to compare whether the two values ​​in the requirement statement are equal. Please answer in the following json format: {comparing = [{"function_name":"%function_name%","functionsignature":"%FUNCTION_SIGNATURE%,"variable_1":"%VARIABLE%","variable_2":"%VARIABLE%","Binary type":"%BINARY_TYPE%","Description":"%Description%"},…],assignments = [{"function_name":"%function_name%","function signature":"%FUNCTION_SIGNATURE%","variable_1":"%VARIABLE%","right value":"%RIGHT_VALUE%","Description":"%Description%"},[…],…}(%ERC721 standard documentation%)".

[0085] (4.2.2) Input the prompt word into GPT to obtain the standard interfaces defined in the ERC721 standard, the function signatures, variable lists, function call relationships, comparison relationships, descriptions and other information corresponding to these interfaces.

[0086] The fifth stage includes the following steps:

[0087] (5.1) Write the prompt words of GPT according to the idea of ​​the thinking chain model (refer to the human problem-solving method, a series of natural language reasoning processes starting from the input problem until the final output conclusion is obtained). First, specify the system context: "You are a smart contract auditor, and you will be asked questions about the code properties. In addition, please strictly follow the output format. You do not need to explain your answer." Then, perform scene matching, write the prompt words for scene matching, and attach the function fragments formed in the slice to the prompt words, and then guide GPT to output the yes and no judgments for the four candidate vulnerability scenarios respectively. Finally, use the prompt words in the attribute matching stage, select the vulnerability scenario that is output as "yes" in the previous step, and add the description of the specified attribute to the prompt words: "Does this smart contract code conform to '[%SCENARIO,;PROPERTY%]'? Please answer 'yes' or 'no'". If GPT answers "yes", it will be added as a candidate.

[0088] (5.2) Obtain the large model detection results of the code snippet for four vulnerabilities. Judgement k Is it "yes" or "no"

[0089] The sixth stage includes the following steps:

[0090] (6.1) First, for the missing Requirements statement vulnerability: the conditions are as follows: Condition ① (P1): Check whether all state variables mentioned in the comments exist in at least one requirement statement. S represents the set of state variables s in the comments, R represents the set of requirements statements r, and Sr is defined as the set of state variables mentioned in r. Condition ② (P2): Extract the binary comparison relations in the comments. For each comparison relation, check whether there is an implementation that satisfies the comparison relation in at least one requirement statement. C represents the set of all binary comparison relations in the comments. If either of the two conditions is not met, the contract is considered to have a missing Requirements statement vulnerability. Its expression is as follows:

[0091] Pl

[0092] P2

[0093]

[0094] (6.2) Secondly, regarding the ERC721 reentrancy vulnerability: Condition ① (P1): The function is not an interface in the openzeppelin framework, but is written independently; Condition ② (P2): The function itself can be called externally, or other functions in the contract that can be called externally can change a state variable in this function; Condition ③ (P3): The internal call of the function includes the onERC721Received function; Condition ④ (P4): After the onERC721Received call, a "read before call" state variable is written. If all four conditions are met, it is considered that the contract has an ERC721 reentrancy vulnerability. Its expression is as follows:

[0095] Pl

[0096] p2

[0097] P3

[0098] P4

[0099]

[0100] (6.3) Then, for the infinite casting vulnerability: Condition ① (P1): There is a read operation on the supply related variables in the mint function; Condition ② (P2): The related variables are not compared with the rarity parameters. If either of the two conditions is not met, it is considered that the contract has an infinite casting vulnerability. Its expression is as follows:

[0101] Pl

[0102] P2

[0103]

[0104] (6.4) Finally, for the public burning vulnerability: Condition ① (P1): There is no burn function or the visibility of the burn function is not public (publicly visible) Condition ② (P2): The burn function checks that the caller must be the NFT owner. If either of the two conditions is not met, the contract is considered to have a public burning vulnerability. Its expression is as follows:

[0105] Pl

[0106] P2:checkOwner(f burn ,caller(f));

[0107]

[0108] According to an embodiment of the present application, there is also provided an electronic device, including: one or more processors;

[0109] A memory for storing one or more programs;

[0110] When the one or more programs are executed by the one or more processors, the one or more processors implement the NFT smart contract vulnerability detection method based on large language agent.

[0111] And provide a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the NFT smart contract vulnerability detection method based on a large language agent.

[0112] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the contents disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0113] It will be appreciated that the present application is not limited to the exact construction that has been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof.

Claims

1. A method for detecting vulnerabilities in NFT smart contracts based on a large language agent, characterized in that: The following steps are involved: (1) Code preprocessing: delete blank lines in the code, delete blank lines in comments, and merge line breaks in function definitions (2) Code slicing: Combined with the application binary interface (ABI) of the smart contract, retrieve the function set F = {fn} in the code, where fn represents the nth function; perform code slicing on the functions in the function set; (3) Build an external knowledge base: Extract the code part ERC721 from the Ethereum official document ERC-721 standard code , including comments; and use the big language tool GPT, enter the code part extracted in the previous step in the prompt, and guide GPT to identify the interfaces, function names, and corresponding parameter definitions, function function descriptions, function key variable check descriptions, and requirements statement necessity descriptions that all NFT smart contracts need to implement: GPT (ERC721Code) → (Interfaces, Functions, Parameters, Descriptions), where GPT represents the big language tool GPT processing, Interfaces represents the interface, Functions represents the function description, Parameters represents the parameter definition, and Descriptions represents the requirements statement necessity description; and form a structured external knowledge base KB = {(Interface i , Function j , Params k ,Desc l )}; (4) Generate prompts based on the knowledge base: Generate prompt words for the large model detection phase and prompt words for the program analysis verification phase; (5) Large model detection: Write GPT prompt words based on the ideas of the thought chain model; Get the code snippet's large model detection results for four vulnerabilities: Results GPT Represents the detection results of the large model for four vulnerabilities. Represents a code snippet, Vul j Represents vulnerability j, Judgment k Represents "yes" or "no"; (6) Program analysis verification: Further judgment is made on the large model detection results in step (5). First, the respective conditions are proposed for the missing Requirements statement vulnerability, ERC721 reentry vulnerability, infinite casting vulnerability and public burning vulnerability to be detected, and finally the NFT smart contract vulnerability detection results are output; if there are vulnerabilities after large model detection and program analysis verification, it is considered that the contract has a vulnerability.

2. The NFT smart contract vulnerability detection method based on large language agent according to claim 1 is characterized in that: In the step (2), code slicing is performed on the functions in the function set, which specifically includes the following sub-steps: (2.1) Traverse each unsliced ​​function in the function set F, analyze the relevant nodes in the abstract syntax tree AST of the function, and construct a function call relationship graph, denoted as CallGraph(f); (2.2) Check each node in the function call graph. If the current node is a sliced ​​function, add the function to be sliced ​​and other functions with slices in the graph to the slice of the current node. For the remaining sliced ​​functions in the call graph, merge the slices. (2.3) Check the code slices and check the external variables read or written by each function in the function sequence to form a read state variable set S read ={S r1 ,S r2 ,...,S rn } and the state variable set S written read ={S r1 ,S r2 ,...,S rn }.

3. The NFT smart contract vulnerability detection method based on large language agent according to claim 1 is characterized in that: The functional function set in the step (2.1) does not include declaration statements of public libraries and private libraries, does not include abstract functions, and does not include declaration statements of interface class functions.

4. The NFT smart contract vulnerability detection method based on large language agent according to claim 1 is characterized in that: The slicing function in step (2.2) is specifically a mapping relationship M slice ={(id,(F seq , S))}, the key in this mapping is the slice id, and its value (F seq ,S) is a combination, where F seq =[f1, f2, ..., f k ] is a sequence of functions in a function call graph starting from a public function as the entry point, and S = {s1, s2, ..., s m }The key variable set is a set of external state variables read or written by each function in the function sequence.

5. The NFT smart contract vulnerability detection method based on large language agent according to claim 1 is characterized in that: In step (4), the large model detection phase prompt words are generated, specifically: scenario attribute prompt words T are generated for four NFT smart contract vulnerabilities vuln ={T reentrant , T requirements , T infinite , T burn }; The four NFT smart contract vulnerabilities are ERC721 reentry, missing Requirements statement, unlimited casting and public burning; Use the prompt word template to form the scenario attribute prompt word "Given the following vulnerability materials, you should summarize the vulnerability 'scenario' and 'attribute' of [% vulnerability name%] in the NFT smart contract, where 'scenario' describes the code function where the vulnerability may occur, and 'attribute' explains the code attribute or operation of the vulnerability; control the length of 'scenario' and 'attribute' to within one sentence respectively, and answer in json format: {scenario:[%SCENARIO%], property:[%PROPERTY%]}"; Then input the prompt word to GPT to get the scenario attribute information about the four vulnerabilities: SP vul ={scenrio vul ,property vul }, where scenario vul Represents the scenario information of the vulnerability vul, property vul Represents the attribute information of the vulnerability vul.

6. The NFT smart contract vulnerability detection method based on large language agent according to claim 1 is characterized in that: The program analysis method verification phase prompt word in step (4) includes the following sub-steps: (4.1) For the missing Requirements statement vulnerability, use the interface, function, parameter and description information in the knowledge base KB to generate prompt words for finding key variables; (4.2) Input the prompt word into GPT to obtain the standard interfaces defined in the ERC721 standard, the function signatures, variable lists, function call relationships, comparison relationships, descriptions and other information corresponding to each standard interface.

7. The NFT smart contract vulnerability detection method based on large language agent according to claim 1 is characterized in that: The step (5) of writing the GPT prompt words according to the idea of ​​the thought chain model includes the following sub-steps: (5.1) First, the system background is specified: "You are a smart contract auditor, and you will be asked questions about the properties of the code; in addition, please strictly follow the output format; you do not need to explain your answers"; (5.2) Perform scene matching and write scene matching prompt words, with the prompt words attached with the function fragments formed in the slice, and then guide GPT to output the true and false judgments for the four candidate vulnerability scenarios respectively; (5.3) Use the prompt words in the attribute matching stage to select the vulnerability scenario that is output as "yes" in the previous step, and add the description of the specified attribute in the prompt words: "Does this smart contract code conform to '[%SCENARIO,;PROPERTY%]'? Please answer 'yes' or 'no'"; if GPT answers "yes", it will be added as a candidate.

8. The NFT smart contract vulnerability detection method based on large language agent according to claim 1 is characterized in that: In step (6), respective conditions are proposed for detection of missing Requirements statement vulnerability, ERC721 reentrancy vulnerability, infinite casting vulnerability and public burning vulnerability, specifically: (6.1) The following conditions are specified for the missing requirements statement vulnerability: Condition ① (P1): Check whether all state variables proposed in the comment exist in at least one requirement statement. S represents the set of state variables s in the comment, and R represents the set of requirements statements r. Define S r is the set of state variables mentioned in r; Condition ② (P2): Extract the binary comparison relations in the comments. For each comparison relation, check whether there is at least one requirement statement that satisfies the implementation of the comparison relation. C represents the set of all binary comparison relations in the comments. If any of the two conditions is not met, the contract is considered to have a missing Requirements statement vulnerability: P1： P2： (6.2) Secondly, regarding the ERC721 reentrancy vulnerability: Condition ① (P1): The function is not an interface in the openzeppelin framework, but is written independently; Condition ② (P2): The function itself can be called externally, or other functions in the contract that can be called externally can change a state variable in this function; Condition ③ (P3): The internal call of the function includes the onERC721Received function; Condition ④ (P4): After the onERC721Received call, a "read before call" state variable is written; If all four conditions are met, it is considered that the contract has an ERC721 reentrancy vulnerability; Its expression is as follows: P1： P2： P3： P4： (6.3) Then, for the infinite casting vulnerability: Condition ① (P1): There is a read operation on the supply related variables in the mint function; Condition ② (P2): The related variables are not compared with the rarity parameters; If either of the two conditions is not met, it is considered that the contract has an infinite casting vulnerability; its expression is as follows: Pl P2, (6.4) Finally, for the public burning vulnerability: Condition ① (P1): There is no burn function or the visibility of the burn function is not public (publicly visible) Condition ② (P2): The caller in the burn function needs to be checked to be the NFT owner; If either of the two conditions is not met, the contract is considered to have a public burning vulnerability; Its expression is as follows: P1： P2:checkOwner(f burn ,caller(f)); After the above steps, the NFT smart contract vulnerability detection results can be output; if there are vulnerabilities after large model detection and program analysis verification, the contract is considered to have vulnerabilities.

9. An electronic device, characterized in that: include: one or more processors; A memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the NFT smart contract vulnerability detection method based on large language agent as described in any one of claims 1-8.

10. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When this instruction is executed by the processor, it implements the steps of the NFT smart contract vulnerability detection method based on a large language agent as described in any one of claims 1-8.

Images