A method for generating a blockchain smart contract semantic graph

Abstract

A blockchain smart contract semantic graph generation method can realize a state diagram of a semantic execution process according to defined smart contract semantic rules, so as to extract effective vulnerability information in a semantic verification process. The present application comprises: defining the BNF syntax and formal semantics of the smart contract, the configuration table related to the state storage, the function call sequence, gradually executing the smart contract according to the formal semantic rules and generating a state execution sequence, extracting the starting state and the terminal state to be verified from the state execution sequence, forming the reachability assertion according to the reachability assertion template, verifying the reachability assertion using the semantic verifier, and generating the semantic graph. The semantic graph comprises smart contract semantic information, semantic control flow information, semantic data flow information, and verification constraint information, and can be used for vulnerability detection analysis and symbolic execution analysis. The present method can display the contract execution process from the formal semantic level and find semantic-level vulnerabilities.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method for generating semantic graphs of blockchain smart contracts. Background Technology

[0002] Blockchain is a distributed database technology that stores data in blocks and uses cryptographic methods to ensure data security and integrity. Smart contracts are automatically executed, immutable programs on the blockchain, relying on the distributed ledger of blockchain technology to ensure the transparency of contract terms. However, if a smart contract has a vulnerability, its execution process can cause significant economic losses that are difficult to repair. Currently, there are various methods to verify smart contracts, such as formal verification, static analysis techniques, dynamic analysis techniques, and data flow analysis techniques.

[0003] Data flow analysis is a common technique in compiler optimization and vulnerability detection, used to obtain and analyze information during program execution. Data flow analysis can analyze the following types of graphs: Control flow graphs are abstract representations of the program execution process, showing all paths traversed during execution. Control flow graphs can be generated based on information from the compilation process and are used for compiler optimization and analysis. Data flow graphs represent the data change process from the perspective of data transfer and processing. Function call graphs are graphical representations of the relationships between different function calls within a program, showing how functions interact with each other. They are generally divided into static call graphs and dynamic call graphs. Static call graphs construct the function call relationships based on the program's source code, without considering the actual execution of the program. Dynamic call graphs represent the control flow of function calls during program execution, showing the function call relationships during program execution. Program dependency graphs are directed graphs representing the control and data dependencies between program statements. Nodes represent program statements, and edges represent dependencies between program statements, including control dependencies (such as conditional statements) and data dependencies (such as variable assignments). However, these graphs are generated by different analysis, execution, and compilation methods, resulting in scattered information and making cross-validation difficult. Semantic graphs are generated based on the execution of semantic rules. They define semantic rules with fine granularity and can scalably display the information generated and needed during program execution, compilation, and analysis at a semantic level. Combined with symbolic execution techniques, key state parameters that need to be tracked are symbolized in the function call sequence, allowing for the exploration of all possible paths of program semantic execution and the discovery of problems overlooked in traditional software testing.

[0004] Formal semantics can be categorized into operational semantics (based on the implementation of programming languages), axiomatic semantics (based on logic and proof), and denotative semantics (based on mathematical objects and functions), etc. It forms the foundation of formal verification and program development, helping developers understand program programming and enabling verifiers to abstract programs and build formal models. In operational semantics, programs are typically described as state transition systems, executed through a series of operational definitions. This invention defines the formal semantics of smart contract languages ​​based on operational semantics. By rewriting the operational semantics definitions, smart contracts written in that language can be executed automatically. Furthermore, the semantic graph generation method of this invention generates the semantic graph of the smart contract.

[0005] The results of existing data flow analysis techniques are limited by the information in the control flow and data flow. The program obtains this information through compilation and execution in a specified compiler and execution environment. This process requires additional data extraction and analysis methods. If there are errors in the compilation process itself, the results are usually incorrect. Moreover, the amount of data in the compilation process is limited, resulting in insufficient information for analysis.

[0006] This invention designs a method for generating semantic graphs for smart contracts based on semantic rules. First, it defines the Backus-Naur Form (BNF) syntax and semantic rules for smart contracts, enabling execution under these rules. Then, a semantic interpreter and a semantic verifier generated from these rules produce a semantic graph. From the data flow and control flow information in this semantic graph, fine-grained function calls, program dependencies, and state transition relationships are analyzed. This rule-driven semantic graph can depict more program characteristics and execution details. Combining user-defined security attributes and function call sequences can further enrich the information in the semantic graph. Summary of the Invention

[0007] A method for generating a semantic graph of a blockchain smart contract, comprising:

[0008] The syntax and semantics are defined according to the smart contract specification, where the syntax is defined in Backus Normal Form (BNF) and the semantics are defined in the form of rules that conform to the rewriting logic.

[0009] The written smart contract semantic set is compiled to generate a semantic interpreter and a semantic verifier;

[0010] A smart contract program that receives user input, including user-defined security attributes and function call sequences;

[0011] The smart contract program is input into the generated semantic interpreter to generate a program execution state sequence. The i-th and j-th steps in the execution state sequence are extracted as state changes in the attribute specification based on the verification attributes. Symbolic constraints are input to form the attribute specification, and the attribute specification is input into the semantic verifier.

[0012] The semantic verifier explores paths based on rewriting and simplification rules to generate a smart contract semantic graph, which includes contract semantics, semantic control flow, semantic data flow, and verification constraint information.

[0013] Semantic graph analysis is performed based on the semantic graph, and the semantic graph analysis includes either symbolic execution or vulnerability detection.

[0014] Based on the results, the smart contract is iteratively optimized until the generated semantic graph meets the verification constraints.

[0015] Preferably, the step of inputting the smart contract program into the generated semantic interpreter to generate a program execution state sequence includes:

[0016] If the user inputs smart contract information, and the initialization information is related to the verification attributes, the user also needs to customize the initialization information. If they are not related, the default initialization information is used, including blockchain information and custom security attributes.

[0017] Create a new contract instance, use the contract instance to call functions in the smart contract, determine the call relationship of the contract functions, obtain the function call sequence, parse the initialization information, and establish the contract's storage stack, which is divided into user account and contract information storage areas;

[0018] According to predefined semantic rules, the smart contract is executed according to the rewrite logic to obtain the smart contract's constraints, execution state sequence, and dynamic information of the storage slot, and the data in the storage stack is updated with the dynamic information.

[0019] Preferably, the semantic verifier explores paths based on rewriting rules and simplification rules to generate a smart contract semantic graph, including:

[0020] The smart contract code is converted according to BNF syntax, and the call sequence of the contract and function, initial account information, and constraint information are input. The code is then converted and reasoned according to the call rules and state transition rules defined based on the rewritten logic.

[0021] The entire inference process is numbered using an inference depth array. Each step generates a set of cells containing information about the smart contract, functions, storage slots, and the execution engine.

[0022] Based on the inference depth array, a series of State sets are obtained. Then, based on branch nodes or potentially problematic states, the initial State that needs to be explored is extracted. i and final state j Then, based on the templates and rules in the reachability assertion generator, the State is...i and State j Perform item-by-item state alignment to generate reachability assertions based on rewrite logic;

[0023] In the reachability proof system, the different state information corresponding to the reachability assertion is extracted, the final state is used as the leaf node of the path exploration, the initial state is used as the root node, the tree-like execution path is explored, and a semantic graph is generated through the semantic verifier.

[0024] Preferably, the extraction involves the initial state (State) to be explored. i and final state j This includes: if the total number of states is small, directly use State0 and State... n As a start and end state.

[0025] Preferably, after generating the semantic graph, the process also includes:

[0026] Based on the results, symbolic execution is performed to symbolize some of the call information in order to iteratively generate more execution paths and capture potential vulnerability information.

[0027] Preferably, the process of creating a new contract instance, using the contract instance to call functions in the smart contract, determining the call relationship of the contract functions, obtaining the function call sequence, parsing initialization information, and establishing the contract's storage stack, which is divided into user account and contract information storage areas, specifically includes:

[0028] Create a new contract instance, use the contract instance to call functions in the smart contract, determine the call relationship of the contract functions, obtain the function call sequence, establish and initialize the contract's storage stack, which is divided into user account and contract information storage areas, each containing multiple storage slots;

[0029] User accounts, also known as external accounts, are applied for on the blockchain and are in the form of the user's public key.

[0030] The contract information storage area is used to store contract account information, variable status information, and caller information;

[0031] The caller can be a user account or a smart contract account. A smart contract account can be represented as:

[0032]

[0033] When a contract call occurs, an account switch will be performed:

[0034]

[0035] User accounts take the form of:

[0036]

[0037] After the contract is invoked by an external account, the external account information is stored in the caller's storage slot:

[0038] .

[0039] Preferably, the constraints can be user-defined, or general security attribute rules can be pre-defined in the form of a constraint library and automatically invoked.

[0040] The execution state sequence represents the function calling logic, calling order, and relationships;

[0041] The storage slot is used to store variables, functions, and contract data during the execution of the smart contract. The information in the storage slot changes dynamically as the execution process progresses.

[0042] Preferably, the execution engine includes a call stack, an external account, a callTrack, and a callState. The call stack includes caller information and storage slots used during the call. The external account is pre-loaded user account information. The callTrack indicates the order of function call execution, and the callState indicates information about the called function.

[0043] Preferably, the reachability assertion generator includes templates and generation rules required for assertion generation, for State. i and State j Perform item-by-item state alignment to generate reachability assertion forms based on rewrite logic:

[0044] .

[0045] The semantic graph is a tree structure, consisting of nodes and directed edges:

[0046]

[0047] The node set includes each state on the execution path, which is related to a defined rule, and each state transition corresponds to a rule:

[0048]

[0049] The initial state of the branch corresponding to the node points to the set of multiple outgoing edges, which is:

[0050] . Attached Figure Description

[0051] The following description will detail some specific embodiments of the invention by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art will understand that these drawings are not necessarily drawn to scale. The objectives and features of the invention will become more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0052] Figure 1 This is an architecture diagram of a method for generating semantic graphs for blockchain smart contracts.

[0053] Figure 2 This is a mechanism for generating and storing the execution state sequence of smart contracts.

[0054] Figure 3 This is a flowchart of the semantic graph generation process. Detailed Implementation

[0055] The purpose of this invention is to provide a method for generating semantic graphs of blockchain smart contracts, constructing a semantic set for smart contracts, including syntax and semantics defined according to the smart contract specification, wherein the syntax is defined in Backus Normal Form (BNF), and the semantics are defined in the form of rules conforming to rewrite logic. Through the aforementioned syntax and semantics, a semantic interpreter and a semantic verifier are generated. The semantic interpreter can automatically obtain the state sequence of the smart contract execution process, and the semantic verifier can generate a semantic graph of the smart contract through path exploration methods.

[0056] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0057] See Figure 1 This invention provides a method for generating semantic graphs of blockchain smart contracts, with the following overall architecture:

[0058] The syntax and semantics are defined according to the smart contract specification, where the syntax is defined in Backus Normal Form (BNF) and the semantics are defined in the form of rules that conform to the rewriting logic.

[0059] The written smart contract semantic set is compiled to generate a semantic interpreter and a semantic verifier;

[0060] The user inputs the smart contract program, which includes user-defined security attributes and function call sequences;

[0061] The smart contract program is input into the semantic interpreter to generate a sequence of program execution states. The user extracts the i-th and j-th steps from the execution state sequence as the state changes in the attribute specification based on the verification attributes. Then, symbolic constraints are input to form the attribute specification, which is then input into the semantic verifier.

[0062] The semantic validator explores paths based on rewriting and simplification rules to obtain a semantic graph of the smart contract. The semantic graph contains contract semantic execution rules, semantic control flow, semantic data flow, and verification constraint information.

[0063] Symbolic execution can be performed based on the generated semantic graph, symbolizing some call information to iteratively generate more execution paths and capture potential vulnerability information;

[0064] Based on the results, the smart contract is iteratively optimized until the generated semantic graph meets the verification constraints.

[0065] See Figure 2 The process and storage mechanism for generating and storing the execution state sequence of a smart contract are described as follows: The user needs to input smart contract information (as shown in ① in the figure). If the initialization information is related to verification attributes, the user also needs to customize the initialization information. If not, the default initialization information can be used, including blockchain information and custom security attributes. A new contract instance is created, and the contract instance is used to call functions in the smart contract to determine the call relationship of the contract functions, obtain the function call sequence, and simultaneously parse the initialization information to establish the contract's storage stack, which is divided into user account and contract information storage areas (as shown in ② in the figure). According to predefined semantic rules, the smart contract is executed according to the rewritten logic (as shown in ③ in the figure), obtaining the smart contract's constraints, execution state sequence, and dynamic information of the storage slots, and updating the data in the storage stack based on this information.

[0066] See Figure 3 The process for generating a semantic graph of smart contract code is described as follows: First, the smart contract code is converted according to BNF syntax to ensure it conforms to the syntax specification. Simultaneously, the contract, function call sequence, initial account information, and constraint information are input, and conversion and reasoning are performed according to the call rules and state transition rules defined based on the rewritten logic. Then, the entire reasoning process is numbered using a Depth array, and each step generates a Cell-type set containing smart contract information, function information, storage slot information (including variables and storage information), and the execution engine.

[0067] Based on the Depth array, a series of State sets are obtained. Then, based on branch nodes or potentially problematic states, the initial State that needs to be explored is extracted. i and final state j If the total number of states is small, State0 and State can be used directly. n This serves as the start and end state. Then, based on the templates and rules in the reachability assertion generator, the State is... i and State jPerform item-by-item state alignment to generate reachability assertions based on rewrite logic.

[0068] Finally, in the reachability proof system, the different state information corresponding to the reachability assertion is extracted, the final state is used as the leaf node of the path exploration, the initial state is used as the root node, the tree-like execution path is explored, and a semantic graph is generated through the semantic verifier.

[0069] Based on the results, symbolic execution can be performed to symbolize some of the call information in order to iteratively generate more execution paths, thereby capturing potential vulnerability information.

[0070] in:

[0071] (1) The specific method for generating the execution state sequence of smart contracts is as follows:

[0072] Use storage slot <cell>The form defines the information involved in smart contract execution and function calls. This form can be nested to form a collection of cells, for example:

[0073] <cell1>

[0074] <cell2>

[0075] < / cell2>

[0076] < / cell1>

[0077] The mechanism for generating and storing the execution state sequence of smart contracts is as follows: Figure 2 As shown:

[0078] The first step requires users to enter at least the smart contract information; other information, such as blockchain information and custom security attributes, can be entered optionally.

[0079] Allows users to define the call sequence of contracts or functions, and by default it iterates through all public functions for calling;

[0080] The second step is to create a new contract instance, use the contract instance to call functions in the smart contract, determine the call relationship of the contract functions, obtain the function call sequence, establish and initialize the contract's storage stack, which is divided into user account and contract information storage areas, each containing multiple storage slots;

[0081] User accounts, also known as external accounts, are applied for on the blockchain and are in the form of the user's public key.

[0082] The contract information storage area is used to store contract account information (the smart contract's account is stored in this area), variable state information, and caller information;

[0083] The caller can be a user account or a smart contract account. Depending on the calling method and the smart contract's coding style, the caller may vary. This is a key piece of information that developers need to be aware of when developing smart contracts. A contract account can be represented as:

[0084]

[0085] When a contract call occurs, an account switch will be performed:

[0086]

[0087] User accounts take the form of:

[0088]

[0089] After the contract is invoked by an external account, the external account information will be stored in the caller's storage slot:

[0090]

[0091] The third step, during subsequent execution, involves executing the smart contract according to predefined semantic rules and the rewritten logic, obtaining the smart contract's constraints, execution state sequence, and dynamic information about the storage slots. These constraints, execution state sequence, and dynamic information about the storage slots can all dynamically affect the values ​​in the storage stack.

[0092] The constraints can be user-defined, or general security attribute rules can be pre-defined in the form of a constraint library and automatically invoked.

[0093] The execution state sequence represents the function calling logic, calling order, and relationships;

[0094] Storage slots are used to store variables, functions, and contract data during the execution of smart contracts. This information changes dynamically as the execution process progresses.

[0095] (2) The specific method for generating the semantic graph of smart contracts is as follows:

[0096] The smart contract is converted according to the syntax defined by BNF. At the same time, the contract, function call sequence, initial account information, and constraint information are input. The conversion and reasoning are performed based on the call rules and state transition rules defined by the rewritten logic. The entire reasoning process is numbered by the Depth array. Each step generates a set of Cell-type collections, such as smart contract information, function information, storage slot information (including variables and storage information), and execution engine.

[0097] The execution engine includes a call stack, external accounts, callTrack, and callState. The call stack contains caller information and storage slots needed during the call. The external account contains pre-loaded user account information. callTrack indicates the order in which function calls are executed. callState represents information about the called function, such as variable values, storage locations, storage types, call order (Depth), call type, and error messages. The execution engine comprehensively reflects the semantic details of the contract call process and can supplement the definition of data that needs to be recorded. All data recording processes satisfy call rules and state transition rules, thus enabling the discovery and verification of scalable new vulnerabilities.

[0098] Based on the execution order array Depth, a series of State sets are obtained. Then, based on the branch nodes or potentially problematic states, the initial State to be explored is extracted. i and final state j If the total number of states is not large, 0 and n can be used directly as the start and end states. This selection method is related to the time required for subsequent verification execution.

[0099] The reachability assertion generator includes the templates and generation rules required for assertion generation, for State. i and State j Perform item-by-item state alignment to generate reachability assertion forms based on rewrite logic:

[0100]

[0101] In the reachability proof system, the different state information corresponding to the reachability assertion is extracted. The final state information is used as the leaf node of the path exploration, and the initial state is used as the root node. The tree-like execution path is explored, and a semantic graph is generated through a semantic verifier. The semantic graph is usually a tree structure, consisting of nodes and directed edges.

[0102]

[0103] The node set includes each state on the execution path, which is related to a defined rule, and each state transition corresponds to a rule:

[0104]

[0105] If some nodes correspond to the initial state of a branch, pointing to a set of multiple outgoing edges, then:

[0106]

[0107] The semantic tree reveals the execution semantic rules, variable states, contract states, called functions, executed smart contract code, remaining rules, execution steps, function call counts, and storage stack information corresponding to each node state. It also supports tracing based on semantic graph variables set for vulnerabilities, exhibiting strong scalability. Based on the results, symbolic execution can be performed, symbolizing some call information to iterate the semantic graph generation process, obtaining more execution paths and capturing potential vulnerability information.

[0108] The beneficial effects of this invention are:

[0109] (1) A semantic graph for smart contracts is proposed. This graph can represent function call relationships, data dependencies, simulate user call sequences, and distinguish caller information. It has the characteristics of symbolic execution and semantic execution, reflecting the execution process of the formal semantics of the program under given rules, as well as the constraint attributes of the symbolic description. It can influence the information and generation process of the graph through semantic definition, thereby achieving the goal of fine-grained and scalable display of the execution characteristics and information of smart contracts. This semantic graph integrates information from control flow graphs, data flow graphs, function call graphs, and program dependency graphs, comprehensively reflecting the program execution process.

[0110] (2) A semantic graph generation process is proposed, including semantic rule-driven cell set generation, reachability assertion generation, reachability assertion proof, and semantic graph generation. This method establishes a formal semantic execution and verification system for smart contracts through semantic rules based on rewriting logic, enabling smart contracts to break away from the traditional compilation and execution environment and reflect the original execution process from a semantic perspective. However, data analysis rules are added. This process can accelerate the semantic graph generation process by selecting different start and end states and optimizing path exploration methods. Furthermore, different syntax parsing rules can realize semantic graphs in different languages, which is scalable and also applicable to the generation of semantic graphs for multilingual interaction and invocation.

[0111] In the above embodiments, all or part of the functions can be implemented by software, hardware, or a combination of software and hardware. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0112] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.< / cell>

Claims

1. A method for generating a semantic graph of a blockchain smart contract, characterized in that, include: The syntax and semantics are defined according to the smart contract specification. The syntax is defined in Backus Normal Form (BNF), and the semantics are defined in the form of rules that conform to the rewriting logic. The semantics related to smart contracts include input contracts, function call sequences, initial account information, and constraint information. The written smart contract semantic set is compiled to generate a semantic interpreter and a semantic verifier; A smart contract program that receives user input, including user-defined security attributes and function call sequences; The smart contract program is input into the generated semantic interpreter. The entire reasoning process is numbered using the reasoning depth array, and a sequence of program execution states is generated. Each step generates a set in the form of a cell, which contains information about the smart contract, function information, storage slot information, and execution engine. Based on the Depth array, a series of State sets are obtained. Through branch nodes or states that are suspected of being problematic, the initial state Statei and the final state Statej that need to be explored are extracted. Then, according to the templates and rules in the reachability assertion generator, the statei and statej are aligned item by item to generate reachability assertions based on rewriting logic. In the reachability proof system, the different state information corresponding to the reachability assertion is extracted, the final state is used as the leaf node of the path exploration, the initial state is used as the root node, the symbolic constraints are input to form the attribute reduction, and the attribute reduction is input into the semantic verifier. The semantic verifier explores paths based on rewriting rules and simplification rules to generate a smart contract semantic graph. The semantic graph contains contract semantic execution rules, semantic control flow, semantic data flow, and verification constraint information. Based on the semantic graph, semantic graph analysis can be performed, and symbolic execution can be performed based on the results. This symbolizes some call information to iteratively generate more execution paths, capture potential vulnerability information, and achieve the effect of vulnerability detection. Based on the results, the smart contract is iteratively optimized until the generated semantic graph meets the verification constraints.

2. The method according to claim 1, characterized in that: The step of inputting the smart contract program into the generated semantic interpreter to generate a program execution state sequence includes: If the user inputs smart contract information, and the initialization information is related to the verification attributes, the user also needs to customize the initialization information. If they are not related, the default initialization information is used, including blockchain information and custom security attributes. Create a new contract instance, use the contract instance to call functions in the smart contract, determine the call relationship of the contract functions, obtain the function call sequence, parse the initialization information, and establish the contract's storage stack, which is divided into user account and contract information storage areas; According to predefined semantic rules, the smart contract is executed according to the rewrite logic to obtain the smart contract's constraints, execution state sequence, and dynamic information of the storage slot, and the data in the storage stack is updated with the dynamic information.

3. The method according to claim 1, characterized in that: The extraction requires exploring the initial state (State). i and final state j This includes: if the total number of states is small, directly use State0 and State... n As a start and end state.

4. The method according to claim 2, characterized in that: The process involves creating a new contract instance, using the contract instance to call functions within the smart contract, determining the function call relationships, obtaining the function call sequence, parsing initialization information, and establishing the contract's storage stack, which is divided into user account and contract information storage areas. Specifically, this includes: Create a new contract instance, use the contract instance to call functions in the smart contract, determine the call relationship of the contract functions, obtain the function call sequence, establish and initialize the contract's storage stack, which is divided into user account and contract information storage areas, each containing multiple storage slots; User accounts, also known as external accounts, are applied for on the blockchain and are in the form of the user's public key. The contract information storage area is used to store contract account information, variable status information, and caller information; The caller can be a user account or a smart contract account. A smart contract account can be represented as: ， When a contract call occurs, an account switch will be performed: ， User accounts take the form of: ， After the contract is invoked by an external account, the external account information is stored in the caller's storage slot: 。 5. The method according to claim 2, characterized in that: The constraints are either user-defined or pre-defined general security attribute rules in a constraint library, and are automatically invoked. The execution state sequence represents the function calling logic, calling order, and relationships; The storage slot is used to store variables, functions, and contract data during the execution of the smart contract. The information in the storage slot changes dynamically as the execution process progresses.

6. The method according to claim 1, characterized in that: The execution engine includes a call stack, an external account, a callTrack, and a callState. The call stack includes caller information and storage slots used during the call. The external account is pre-loaded user account information. The callTrack indicates the order in which function calls are executed, and the callState indicates information about the called function.

7. The method according to claim 1, characterized in that: The reachability assertion generator includes templates and generation rules required for assertion generation, for State. i and State j Perform item-by-item state alignment to generate reachability assertion forms based on rewrite logic: ， The semantic graph has a tree structure, consisting of nodes and directed edges. composition: ， The node set includes each state on the execution path, which is related to a defined rule, and each state transition corresponds to a rule: ， The initial state of the branch corresponding to the node points to a set of multiple outgoing edges, which is: 。

Images