Smart contract functional vulnerability detection method and system based on invariant verification

Abstract

The present invention proposes a method and system for detecting functional vulnerabilities in smart contracts based on invariant verification. The method includes: defining the functional vulnerability category of the smart contract to be detected; inputting and preprocessing the smart contract source code file to be detected; using a large language model to pre-analyze potential vulnerabilities and their types; using the large language model to detect key variables or key statements in the function code with potential vulnerabilities, using these key variables and key statements to generate an invariant checker, and inserting the checker into the smart contract source code; establishing a verification model for the invariant checker based on the principle of dynamic fuzz testing; using the verification model to verify the source code with the invariant checker inserted, and outputting the detection results. The present invention realizes efficient and automated analysis of smart contracts, solves the technical challenge of difficult logical relationship analysis in smart contract code, and improves the efficiency of smart contract functional vulnerability detection.

Description

Technical Field

[0001] The present invention relates to the technical field of smart contract vulnerability detection, and in particular to a method and system for detecting functional vulnerabilities in smart contracts based on invariant verification. Background Art

[0002] Smart contracts are applications that run on blockchain platforms. They define a set of rules that are automatically enforced through code. Once published on a blockchain platform, a smart contract cannot be deleted, and user interactions with it are tamper-proof and irreversible. Therefore, smart contracts have a wide range of applications in areas such as digital currency trading and supply chain management.

[0003] However, if exploitable vulnerabilities exist in smart contracts, the resulting economic losses can be irreversible. Among existing smart contract vulnerabilities that have caused actual harm, functional vulnerabilities account for the vast majority. These functional vulnerabilities are closely related to the business transaction rules defined in smart contracts, making them extremely difficult to detect. Existing detection methods often rely on manual auditors to analyze the smart contract code and related business operations, extracting a set of logical dependencies relevant to functional vulnerability analysis, and then verifying them one by one. While existing technologies can detect some functional vulnerabilities, they rely heavily on manual labor, resulting in inefficient analysis and a low level of automation. Therefore, in the field of smart contract security, there is an urgent need for a method and system that can automatically analyze and verify the logical relationships within smart contracts, thereby enabling the detection of functional vulnerabilities in smart contracts. This would be of great value in improving the security of smart contracts. Summary of the Invention

[0004] In view of the above background, the present invention aims to provide a method and system for detecting functional vulnerabilities in smart contracts based on invariant verification.

[0005] In order to achieve the above-mentioned object of the invention, the present invention provides the following technical solutions:

[0006] The present invention proposes a method for detecting functional vulnerabilities in smart contracts based on invariant verification, comprising the following steps:

[0007] S1, defines the type of smart contract functional vulnerability to be detected;

[0008] S2, input the smart contract source code to be analyzed and preprocess it into multiple smart contract core function codes;

[0009] S3, based on the type of functional vulnerabilities in the smart contract to be detected, uses a large language model to pre-analyze the potential vulnerabilities and vulnerability types of the core function codes of each smart contract;

[0010] S4: Use the large language model to detect the core function code with potential vulnerabilities, obtain key variables or key statements therein, select an invariant checker template based on the vulnerability type of the potential vulnerability, fill the key variables or key statements into the invariant checker template, generate an invariant checker, and insert the invariant checker into the smart contract source code;

[0011] S5. Establish a verification model for the invariant checker, use the verification model to analyze the smart contract source code with the invariant checker inserted, and verify whether the pre-analyzed potential vulnerability in the smart contract source code exists. If so, output the potential vulnerability and its vulnerability type as the functional vulnerability detection result.

[0012] Preferably, step S5 includes the following sub-steps:

[0013] 1) Create two sets: contract execution operation and contract status pair set C, and initial contract status set C s ; Define and initialize the intermediate variable s mut , t mut , and set the verification time for the verification model;

[0014] 2) Randomly obtain a program execution operation transaction and program status pair (s, t) from the contract execution operation and contract status pair set C, where s represents the contract status and t represents the contract execution operation

[0015] 3) Generate a random number between 0 and 1. If the generated random number is greater than the set probability P, the contract execution operation t is mutated and the mutated value is assigned to the variable t. mut , and keep the state s unchanged, and assign the contract state s to the variable s mut ; Otherwise, from the initial contract state set C s Randomly obtain the next contract state and assign it to variable s mut , and keep transaction t unchanged, assign the contract execution operation t to variable t mut ;

[0016] 4) With variable s mut The variable t is the executed contract state. mut For program execution, execute the smart contract source code with the invariant checker inserted to obtain the new contract state s′ after execution;

[0017] 5) If this round of program execution is worth including, then (s mut , t mut ) is added to the set C as a new contract execution operation and contract state pair; if this round of program execution is worth including and the new contract state s′ is not in the initial contract state set C sThen add the new contract state s′ to the set C s middle;

[0018] The criterion for judging whether a program execution is worth including is whether this round of program execution increases the program coverage. If the program coverage is increased, then this round of program execution is worth including, otherwise not.

[0019] 6) Repeat sub-steps 2)-5) above until a conflict occurs in the invariant in the smart contract source code, or the repeated execution time of sub-steps 2)-5) exceeds the runtime verification time; if a conflict occurs in the invariant in the smart contract source code, trace back to the core function code related to the invariant checker inserted in the source code. The potential vulnerability in the core function code is a functional vulnerability. Otherwise, the potential vulnerability in the core function code does not exist.

[0020] The present invention also proposes a smart contract functional vulnerability detection system based on invariant verification, which is used to implement the above-mentioned smart contract functional vulnerability detection method.

[0021] Compared with the prior art, the present invention has the following beneficial effects:

[0022] (1) The present invention proposes a method and system for detecting functional vulnerabilities in smart contracts based on invariant verification. The method and system proposed in the present invention can perform efficient and automated analysis of smart contracts, reducing the dependence of the smart contract functional vulnerability analysis process on manual labor, and greatly improving the efficiency of smart contract functional vulnerability detection.

[0023] (2) This paper proposes a technique for automatically generating functional vulnerability detection invariants based on an invariant checker template. This technique draws on the audit experience of outstanding human auditors to design an invariant checker template. It also utilizes a large language model to perform reasoning analysis on smart contract code, automatically generating an effective smart contract invariant checker. This technique combines historical experience summarized by humans with the uniqueness of code in different smart contracts to generate an invariant checker, thus addressing the technical challenge of difficult logical relationship analysis in smart contract code.

[0024] (3) The present invention proposes an invariant checker verification model based on the principle of dynamic fuzz testing. This verification model continuously generates valuable test sequences for analyzing functional vulnerabilities in smart contracts by analyzing and mutating states and state-transaction pairs that are valuable to mine during program execution, thereby verifying the invariant checker. The dynamic execution verification method ensures that the vulnerabilities detected and analyzed by the present invention are verifiable and real. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1This is a flow chart of a method for detecting functional vulnerabilities in smart contracts based on invariant verification according to the present invention;

[0026] Figure 2 A flow chart of the verification model execution based on dynamic fuzz testing of the present invention;

[0027] Figure 3 This is a diagram of the overall architecture of a smart contract functional vulnerability detection system based on invariant verification according to the present invention. DETAILED DESCRIPTION

[0028] The present invention will be further described in detail below with reference to the accompanying drawings and examples. It should be noted that the following examples are intended to facilitate understanding of the present invention and do not have any limiting effect on the present invention.

[0029] The present invention provides a method for detecting functional vulnerabilities in smart contracts based on invariant verification. The specific process is as follows: Figure 1 As shown, the specific implementation of each step is as follows:

[0030] Step 0: Define the type of smart contract functional vulnerability that the present invention intends to detect. Design an invariant checker template based on the characteristics of the smart contract functional vulnerability.

[0031] Specifically, this embodiment intends to detect ten types of vulnerabilities, including contract token manipulation vulnerabilities caused by automatic exchange, contract token value manipulation vulnerabilities caused by non-automatic exchange, unauthorized contract token transfer vulnerabilities, contract token authorization mechanism logic error vulnerabilities, checkpoint save sequence error vulnerabilities, contract token update calculation sequence error vulnerabilities, contract token allocation calculation mechanism error vulnerabilities, voting mechanism manipulation vulnerabilities, contract token illegal locking vulnerabilities, and lock control mechanism error vulnerabilities. Vulnerability types can also be designed according to the needs of those skilled in the art.

[0032] Invariants are mathematical constraints that always hold true at specific lines of code during the normal operation of a smart contract. These constraints include the numerical relationships between variables and the range of their values. An invariant checker verifies the validity of invariants in a smart contract. The invariant checker template is the invariant checker without the variables to be tested and the program location where it is to be inserted. These variables are typically represented by different symbols in different smart contract codes.

[0033] Specifically, this embodiment designs six types of checker templates: an invariant checker template for detecting changes in contract token value, an invariant checker template for detecting changes in contract token exchange rate, an invariant checker template for detecting changes in contract token quantity, an invariant checker template for checking statement execution order, an invariant checker template for checking the security of contract token allocation mechanisms, and an invariant checker template for checking state security. These six types of invariant checker templates generate invariant checkers after the variables to be tested are populated and the program location to be inserted is determined.

[0034] Among them, the invariant checker used to detect changes in contract token value can detect contract token manipulation vulnerabilities caused by automatic exchange; the invariant checker used to detect changes in contract token exchange rate can detect contract token value operation vulnerabilities caused by non-automatic exchange; the invariant checker used to detect changes in contract token quantity can detect unauthorized transfer vulnerabilities of contract tokens, logical errors in the contract token authorization mechanism, and illegal locking of contract tokens; the invariant checker used to detect statement execution order can detect checkpoint saving order errors and contract token update calculation order errors; the invariant checker used for contract token allocation mechanism security detection can detect contract token allocation calculation mechanism errors; the invariant checker used for state security detection can detect voting mechanism manipulation vulnerabilities.

[0035] Step 1: Obtain the smart contract source code file and perform preprocessing operations.

[0036] Specifically, the input can be a smart contract source code file or an on-chain address. If the input is a source code file, preprocessing and analysis will be performed directly. If the input is an on-chain address, the smart contract source code file corresponding to the address will be crawled and downloaded, and then preprocessing and analysis will be performed.

[0037] Specifically, preprocessing of smart contract code involves filtering analysis, code partitioning, and establishing mapping relationships. Filtering analysis utilizes heuristic rules to filter out smart contract code irrelevant to vulnerability analysis, retaining the core smart contract code. Code partitioning divides the core smart contract code into function-based granularity, generating smart contract function codes for subsequent analysis. Establishing mapping relationships involves creating a three-level mapping table (project-contract-function) between each smart contract function code, the smart contract to which the function code belongs, and the smart contract project to which the smart contract belongs.

[0038] Step 2: Use a large language model to analyze the smart contract code and pre-analyze potential vulnerable functions and their vulnerability types.

[0039] Specifically, this step proposes a multi-round query strategy for the large language model to pre-analyze potential vulnerability functions. The multi-round query strategy guides the large language model to gradually analyze and reason about the smart contract function code, so that the large language model can make reasonable responses. The specific multi-round query includes the following three rounds:

[0040] (1) The first round is to issue task instructions to the large language model, informing it that it will perform tasks such as reading, understanding, auditing, and security analysis of smart contract codes;

[0041] (2) The second round is to input the core function code of the smart contract to be analyzed into the large language model, issue query instructions to the large language model, let the large language model analyze the meaning of this code and the specific business covered, and let the large language model format the output. The query instructions in the second round are designed based on common smart contract business. If the response of the large language model in the second round of query is an empty set, it will not enter the third round of query, and it will be deemed that there are no potential vulnerabilities in the core function code.

[0042] (3) The third round is to input the smart contract code to be analyzed and the information responded by the large language model in the second round of inquiry to the large language model, issue inquiry instructions to the large language model, and let the large language model analyze the potential vulnerability types in this section of code. The potential vulnerability types must be one or more of the smart contract functional vulnerability types to be detected in step 0, and let the large language model format the output. The inquiry instructions in the third round are designed specifically based on the smart contract functional vulnerability types to be detected defined in step 0.

[0043] If the response of the large language model in the third round of inquiries is not an empty set, the next step of analysis will be carried out on the function code and potential vulnerabilities. Otherwise, the analysis of the function code will be terminated.

[0044] Step 3: Use the large language model to select the required invariant checker template for the key variables or key statements in the potential vulnerability function according to the potential vulnerability type determined in step 2, and fill the key variables and key statements into the invariant checker template to generate the invariant checker, and then insert the invariant checker into the smart contract source code.

[0045] Specifically, if multiple potential vulnerabilities are identified in step 2, an invariant checker template is selected for each potential vulnerability. Key variables or statements in the corresponding potentially vulnerable function are inserted into the corresponding invariant checker template, resulting in multiple smart contract source codes with invariant checkers inserted. These source codes are then individually analyzed in subsequent steps. The method of inserting invariant checkers into smart contract source code is well known in the art and will not be described in detail herein.

[0046] Specifically, in this step, the large language model query strategy used to identify key variables and statements guides the large language model to perform variable identification and statement analysis on the smart contract function code, so that the large language model can extract the correct information. The specific multi-round query includes the following two rounds:

[0047] (1) The first round is to issue task instructions to the large language model, informing it that it will perform variable recognition and statement analysis in the smart contract code;

[0048] (2) The second round is to input the smart contract code to be analyzed into the large language model and issue query instructions to the large language model: let the large language model extract the key variables and key statements required by the query instructions, and let the large language model format the output.

[0049] Specifically, the key variables and key statements required by different invariant checker templates are different. The invariant checker template used for contract token value change detection needs to fill in the variable used to store the token value to be detected; the invariant checker template used for contract token exchange rate change detection needs to fill in the variable used to store the number of input tokens and the variable used to store the number of output tokens during the exchange process; the invariant checker template used for contract token quantity change detection needs to fill in the variable used to store the token change quantity, the variable used to store the address of the stakeholders of this round of transactions, and the variable used to represent the authorization or locking behavior; the invariant checker template used for statement execution order detection needs to fill in two key statements for the execution order to be checked; the invariant checker template used for contract token allocation mechanism security detection needs to fill in the variable used to store the allocation share to be detected, the variable used to store the token to be converted into the allocation share, and the variable used to store the address of the stakeholders of this round of transactions; the invariant checker template used for state security detection needs to fill in the variable used to store the state to be detected and the statement that triggers the state change.

[0050] Step 4: Based on the principle of dynamic fuzz testing, a verification model for the invariant checker is established.

[0051] Specifically, the verification model generates a variety of different input execution programs to cover various situations during program execution and comprehensively verify the invariant checker. The establishment and execution process of the verification model includes the following sub-steps, such as Figure 2 As shown:

[0052] Sub-step 401, define and initialize the model. This sub-step creates two sets: contract execution operation and contract state pair set C and initial contract state set C s , define and initialize the intermediate variable s mut , t mut, and set the verification time for the verification model.

[0053] The contract execution operation and contract state pair set C and the initial contract state set C s Specifically, one or several possible contract execution operations and contract state pairs (s, t) that may appear during the execution of the smart contract program are pre-set to form a set C, and one or several possible initial contract states of the program execution are pre-set to form a set C s Where s represents the contract status during program execution, t represents the contract execution operation, and a contract execution operation refers to executing the contract program once after entering a set of input data.

[0054] Sub-step 402: Select a contract execution operation and contract status pair to start this round of execution. Specifically, a contract execution operation and contract status pair (s, t) is randomly obtained from the set C.

[0055] Sub-step 403, input mutation strategy selection. Specifically, generate a random number between 0 and 1. If this random number is greater than the set probability P, execute mutation strategy 1: mutate the contract execution operation t to generate t mut , and keep the contract state s unchanged, and assign s to s mut Otherwise, execute mutation strategy 2: from the initial contract state set C s Get the next contract status s mut , and keep the contract execution operation t unchanged, assign t to t mut The mutation refers to bit-wise reversal, integer addition and subtraction arithmetic operations, sequence content replacement, etc. of the program execution operation sequence.

[0056] Sub-step 404, execute the contract program. Specifically, in the contract state s mut Execute the contract execution operation t mut , obtain the new contract state s′ after execution and the key information f observed during this round of program execution. The key information f refers to the characteristic information that can reflect the execution status of this round of program, including the change information of program state and memory data.

[0057] Sub-step 405, evaluate the results of this round of loop. Specifically, based on the key information f observed during this round of program execution, determine whether this round of program execution is worth including. If the program execution is worth including, then the contract execution operation and contract status (s mut , t mut ) is added to the set C. If this round of execution is worth including and the new contract state s′ is not in the set C s Then add the contract state s′ to the set C sSpecifically, the criterion for determining whether a program execution is worth inclusion is whether the current round of program execution increases the program's coverage. Program coverage describes the proportion and extent of source code tested within a program. If the program coverage increases, the current round of execution is worth inclusion; otherwise, it is not.

[0058] Sub-step 406 repeats sub-steps 402-405 until an invariant conflict occurs, or the repetition time of sub-steps 402-405 exceeds the runtime verification time. The invariant conflict refers to the invariant defined in the invariant checker inserted into the source code conflicting during program execution.

[0059] Step 5: Use the verification model to verify the source code with the invariant checker inserted.

[0060] Specifically, if the invariant checker triggers an exception during the verification process, it proves that there is a potential vulnerability in the contract code that was inferred during the pre-analysis. Otherwise, verification is performed according to the above sub-steps 401-406 using the verification model.

[0061] Based on the same inventive concept, this embodiment also provides a smart contract functional vulnerability detection system based on invariant verification, such as Figure 3 As shown, it specifically includes the following modules:

[0062] Input module: This module is used to read the source code of the smart contract project to be analyzed.

[0063] Specifically, if the input content is a source code file, it is read directly; if the input content is a smart contract address, the smart contract source code file at that address on the chain is downloaded and then read.

[0064] Data preprocessing module: This module is used to filter and analyze the smart contract code, divide the code and establish mapping relationships, and extract the smart contract core function code required for subsequent execution and analysis.

[0065] Vulnerability pre-analysis module: This module uses a large language model to conduct multiple rounds of inquiries on the core function code of the smart contract, gradually analyzing and inferring potential vulnerabilities and their types.

[0066] Invariant checker generation module: This module uses a large language model to analyze key variables or key statements in the core function code with potential vulnerabilities, and fills these key variables and key statements into the invariant checker template to generate an invariant checker, which is then inserted into the smart contract code.

[0067] Verification module: This module establishes a verification model for the invariant checker based on the principle of dynamic fuzz testing, and uses the established verification model to verify the invariant checker to verify whether the potential vulnerabilities pre-analyzed in the smart contract code exist.

[0068] Output module: This module is used to output the vulnerability results after verification.

[0069] As for the system embodiment, since it basically corresponds to the method embodiment, the relevant parts can be referred to the partial description of the method embodiment, and the implementation methods of the remaining modules will not be repeated here. The system embodiment described above is only illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of the present invention. Ordinary technicians in this field can understand and implement it without paying any creative work.

[0070] Embodiments of the system of the present invention can be applied to any device with data processing capabilities, such as a computer or other device. System embodiments can be implemented through software, hardware, or a combination of software and hardware. For example, a software implementation, as a logical device, is implemented by a processor of any device with data processing capabilities, reading corresponding computer program instructions from non-volatile memory into internal memory and executing them.

[0071] The embodiments described above provide a detailed description of the technical solutions and beneficial effects of the present invention. It should be understood that the above are only specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, supplements and equivalent substitutions made within the scope of the principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for detecting functional vulnerabilities in smart contracts based on invariant verification, characterized in that: The following steps are involved: S1: Define the type of smart contract functional vulnerability to be detected; S2: Input the smart contract source code to be analyzed and preprocess it into multiple smart contract core function codes; S3: Based on the type of functional vulnerability in the smart contract to be detected, the large language model is used to pre-analyze the potential vulnerabilities and vulnerability types of the core function codes of each smart contract. The pre-analysis specifically uses a multi-round query strategy to guide the large language model to analyze the core function codes of each smart contract one by one to determine whether the code contains the type of functional vulnerability in the smart contract to be detected. The multi-round query includes the following three rounds: The first round is to define a large language model to perform reading, understanding, auditing, and security analysis of smart contract code; The second round involves inputting the core function code of the smart contract to be analyzed into the large language model and issuing query instructions to the large language model. The query instructions guide the large language model to analyze the meaning of this code segment and the specific business covered, and then output it; The third round involves inputting the core function code of the smart contract to be analyzed and the information replied by the large language model in the second round of inquiries into the large language model, and issuing inquiry instructions to the large language model. The inquiry instructions are designed based on the types of functional vulnerabilities of the smart contract to be detected defined in step S1, including instructing the large language model to analyze and output potential vulnerabilities and potential vulnerability types in the current code segment. The potential vulnerability types are one or more types of functional vulnerabilities of the smart contract to be detected. S4: Use the large language model to detect the core function code with potential vulnerabilities, obtain key variables or key statements therein, select an invariant checker template based on the vulnerability type of the potential vulnerability, fill the key variables or key statements into the invariant checker template, generate an invariant checker, and insert the invariant checker into the smart contract source code; S5: Establish a verification model for the invariant checker, use the verification model to analyze the smart contract source code with the invariant checker inserted, and verify whether the pre-analyzed potential vulnerability in the smart contract source code exists. If so, output the potential vulnerability and its vulnerability type as the functional vulnerability detection result.

2. The method for detecting functional vulnerabilities in smart contracts based on invariant verification according to claim 1, characterized in that: In step S1, the types of functional vulnerabilities of the smart contract to be detected include: token value operation vulnerabilities caused by automatic token exchange, token value operation vulnerabilities caused by non-automatic token exchange, unauthorized token transfer vulnerabilities, token authorization mechanism logic error vulnerabilities, checkpoint save order error vulnerabilities, contract token update calculation order error vulnerabilities, contract token allocation calculation mechanism error vulnerabilities, voting mechanism manipulation vulnerabilities, contract token illegal locking vulnerabilities and locking control mechanism error vulnerabilities.

3. The method for detecting functional vulnerabilities in smart contracts based on invariant verification according to claim 1, characterized in that: In step S2, the preprocessing includes filtering analysis and code segmentation; the filtering analysis uses heuristic rules to filter out smart contract codes that are not relevant to vulnerability analysis, and retain the core code of the smart contract; The code division is to divide the core code of the smart contract into functions as granularity units to obtain multiple smart contract core function codes.

4. The method for detecting functional vulnerabilities in smart contracts based on invariant verification according to claim 1, wherein: In step S4, the use of the large language model for key variables or key statements in the core function code with potential vulnerabilities is specifically: using the large language model query strategy for identifying key variables and statements, guiding the large language model to perform variable identification and statement analysis on the core function code of the smart contract, so that the large language model extracts the key variables or key statements in the core function code.

5. The method for detecting functional vulnerabilities in smart contracts based on invariant verification according to claim 4 is characterized in that: The large language model query strategy for identifying key variables and sentences includes the following two rounds: The first round is to define the large language model that will perform variable recognition and statement analysis in the smart contract code; The second round is to input the core function code of the smart contract that needs to be analyzed into the large language model, and issue query instructions to the large language model. The query instructions include instructing the large language model to extract the required variables and statements and output them.

6. The method for detecting functional vulnerabilities in smart contracts based on invariant verification according to claim 4 or 5, characterized in that: In step S4, the key variables or key statements in the potential vulnerability function are confirmed according to the type of the invariant checker template: if the invariant checker template is an invariant checker template for detecting changes in the value of contract tokens, the key variables or key statements are variables for storing the value of the token to be detected; if the invariant checker template is an invariant checker template for detecting changes in the exchange rate of contract tokens, the key variables or key statements are variables for storing the number of input tokens and variables for storing the number of output tokens during the exchange process; if the invariant checker template is an invariant checker template for detecting changes in the number of contract tokens, the key variables or key statements are variables for storing the number of token changes and variables for storing the profit of this round of transactions. Variables for stakeholder addresses and variables for indicating authorization or locking behavior; if the invariant checker template is an invariant checker template for statement execution order detection, the key variables or key statements are two key statements for checking the execution order; if the invariant checker template is an invariant checker template for contract token allocation mechanism security detection, the key variables or key statements are variables for storing the allocation shares to be detected, variables for storing the tokens to be converted into the allocation shares, and variables for storing the addresses of stakeholders in this round of transactions; if the invariant checker template is an invariant checker template for state security detection, the key variables or key statements are variables for storing the state to be detected and statements for triggering state changes.

7. The method for detecting functional vulnerabilities in smart contracts based on invariant verification according to claim 1, characterized in that: In step S5, the establishment of a verification model for the invariant checker, using the verification model to analyze the smart contract source code into which the invariant checker is inserted and verifying whether the pre-analyzed potential vulnerabilities in the smart contract source code exist, includes the following sub-steps: 1) Create two sets: contract execution operation and contract status pair sets , initial contract state set ;Define and initialize intermediate variables , and set the verification time for the verification model; 2) From the contract execution operation and contract status pair collection Randomly obtain a program execution operation transaction and program status pair ,in Indicates the contract status. Indicates the contract execution operation; 3) Generate a random number between 0 and 1. If the generated random number is greater than the set probability , then execute the operation on the contract Perform mutation and assign the mutated value to the variable , and keep the state unchanged, and the contract status Assign to a variable ; Otherwise, from the initial contract state set Randomly obtain the next contract state and assign it to a variable , and keep trading No change, execute the contract Assign to a variable ; 4) Using variables The executed contract state, variable Execute the program to execute the smart contract source code with the invariant checker inserted to obtain the new contract state after execution ; 5) If this round of program execution is worth including, Added to the collection as a new contract execution operation and contract state pair middle; If this round of program execution is worth including and the new contract status Not in the initial contract state collection In the new contract status Add to Collection middle; The criterion for judging whether this round of program execution is worth including is whether this round of program execution increases the program coverage. If so, then this round of program execution is worth including, otherwise not. 6) Repeat sub-steps 2)-5) above until an invariant conflict occurs in the smart contract source code, or the repeated execution time of sub-steps 2)-5) exceeds the runtime verification time. If an invariant conflict occurs in the smart contract source code, trace back to the core function code related to the invariant checker inserted in the source code. The potential vulnerability in the core function code is a functional vulnerability. Otherwise, the potential vulnerability in the core function code does not exist.

8. A smart contract functional vulnerability detection system based on invariant verification, used to implement the method described in claim 1, characterized in that: The system specifically includes: Input module, used to read the smart contract source code to be analyzed; The data preprocessing module is used to preprocess the smart contract source code to obtain multiple smart contract function codes; The vulnerability pre-analysis module uses a large language model to pre-analyze key variables or key statements in the core function code that may contain potential vulnerabilities; An invariant checker generation module, configured to fill the key variables and key statements into the invariant checker template, generate the invariant checker, and insert the checker into the smart contract source code; A verification module, configured to establish a verification model for the invariant checker, and use the established verification model to analyze the source code of the smart contract into which the invariant checker is inserted, and to verify whether the pre-analyzed potential vulnerabilities in the smart contract code exist; The output module is used to output the verified functional vulnerability detection results.

Images