Smart contract oriented execution compatibility detection method and system

Abstract

A smart contract-oriented execution compatibility detection method and system, in the offline stage, the structured representation model of Ethereum execution semantics is constructed and maintained, the behaviors of operation codes in different execution environments are uniformly modeled through executable behavior specifications, and the behaviors of operation codes lacking executable behavior specifications are completed and checked to form an operation code behavior knowledge base that can be used for subsequent analysis; in the online stage, bytecode analysis is performed on the target smart contract, operation code facts located on the key execution path are extracted, and the executable behavior specifications corresponding to the operation codes in different execution environments are retrieved based on the structured representation model of execution semantics, and the execution semantics and resource consumption rules are compared, thereby generating the execution compatibility analysis result of the smart contract in the target execution environment. The present application can provide smart contract developers with operation code granularity compatibility analysis results of smart contracts in different EVM compatible chains.

Description

Technical Field

[0001] This invention relates to a technology in the field of smart contracts, specifically a method and system for detecting the execution compatibility of smart contracts. Background Technology

[0002] Existing smart contract compatibility testing technologies typically use the contract as a whole as the testing object, which can only determine whether there are differences in execution results under different operating environments. It is difficult to conduct fine-grained analysis of the specific reasons for the differences, resulting in unclear sources of differences and affecting problem localization and subsequent processing. Summary of the Invention

[0003] This invention addresses the shortcomings of existing technologies, which cannot perform fine-grained analysis and can only detect the state during operation. It proposes a method and system for executing compatibility testing of smart contracts. Before deploying a smart contract, it analyzes the differences in the execution behavior of the smart contract in different Ethereum Virtual Machine execution environments, and can provide smart contract developers with compatibility analysis results at the opcode granularity level under different EVM compatible chains.

[0004] This invention is achieved through the following technical solution:

[0005] This invention relates to a method for execution compatibility testing of smart contracts. In the offline phase, an Ethereum execution semantic structured representation model is constructed and maintained. The behavior of opcodes in different execution environments is uniformly modeled using executable behavior specifications. For opcodes lacking executable behavior specifications, the model is completed and verified to form a knowledge base of opcode behavior that can be used for subsequent analysis. In the online phase, bytecode analysis is performed on the target smart contract to extract opcode facts located on key execution paths. Based on the execution semantic structured representation model, the executable behavior specifications corresponding to the opcodes in different execution environments are retrieved. Differences in their execution semantics and resource consumption rules are compared, thereby generating execution compatibility analysis results for the smart contract in the target execution environment.

[0006] The offline phase specifically involves: constructing a graph-based execution semantic structured representation model to uniformly describe and manage opcode behavior in different Ethereum Virtual Machine execution environments. This model utilizes the relationship between execution environments and opcode behavior to describe the execution semantics and resource consumption behavior of opcodes in the corresponding execution environment. The target execution environment is represented as an execution environment formed by introducing opcode behavior modifications based on the parent execution environment. Based on the evolution relationship between execution environments, the unmodified opcode behavior in the parent execution environment is inherited.

[0007] The execution semantic structured representation model includes:

[0008] ① Execution environment entity, which represents a specific Ethereum Virtual Machine compatible execution environment and is associated with information used to identify the execution environment version;

[0009] ② Opcode entity, used to represent the opcode instruction in the virtual machine, and associated with identification information such as opcode name and byte value, so as to achieve a unique mapping of the opcode instruction during bytecode parsing;

[0010] ③ Opcode behavior entity, used to represent the execution behavior characteristics of the opcode in a specific execution environment, and bound to the corresponding executable behavior specification to carry the complete execution semantics of the opcode in the target execution environment, including stack processing behavior, resource consumption rules, semantic execution rules and program counter update rules. It can also optionally be associated with natural language summary information to assist human understanding of opcode behavior;

[0011] ④ Improve the proposal entity to represent a protocol improvement proposal or execution environment change description that affects the behavior of the opcode, and associate it with information such as proposal number, content summary or document fragment to support the tracing of the source of behavior change;

[0012] ⑤ Opcode behavior modification entity, used to represent the changes in execution behavior introduced for a specific opcode during the evolution of the execution environment version. It records the modified opcode and the relationship between the opcode behavior before and after the modification, so as to support the comparative analysis of the execution semantic evolution path.

[0013] The relationships between entities in the execution semantic structured representation model include: establishing evolutionary relationships between execution environment entities to depict the inheritance path of the compatible chain based on the main chain fork version or its own historical version; establishing relationships between execution environment entities and opcode behavior entities to represent the opcode behavior that actually takes effect in a certain execution environment, enabling the execution environment to determine the execution semantics of each opcode through the opcode behavior entity; establishing correspondence relationships between opcode behavior entities and opcode entities to indicate the specific opcode instruction targeted by the behavior entity, realizing opcode semantic anchoring; establishing interaction relationships between opcode behavior modification entities and opcode behavior entities before and after modification to depict the behavior evolution process of the same opcode under different execution environment versions; establishing relationships between improvement proposal entities and opcode behavior modification entities to identify the opcode behavior changes introduced by specific protocol improvement proposals or execution environment change descriptions, thereby recording the source basis of behavior changes; and establishing reference relationships between execution environment entities and improvement proposal entities to support proposal aggregation retrieval and change backtracking at the execution environment version level.

[0014] In the graph structure described above, when a target execution environment evolves from a parent execution environment, an evolution relationship is established between the target execution environment entity and its parent execution environment entity to represent the inheritance relationship of the target execution environment to the opcode behavior entity in the parent execution environment.

[0015] In the target execution environment entity, the opcode behavior entity formed after being modified by the opcode behavior entity is associated. For opcode behavior entities that have not been modified, they are inherited by the parent execution environment entity through evolution relationship.

[0016] Preferably, when the opcode behavior corresponding to the target execution environment lacks an executable behavior specification or the executable behavior specification is unavailable, an executable behavior specification is generated and tested and corrected to complete the execution semantic structured representation model.

[0017] The aforementioned generation of executable behavior specifications specifically includes:

[0018] Based on the executable behavior specifications of the opcodes in the parent execution environment and the opcode behavior modification information corresponding to the differences in execution behavior, i generates candidate executable behavior specifications for the opcodes. Specifically, based on the executable behavior specifications of the corresponding opcodes in the parent execution environment and the opcode behavior modification information, candidate executable behavior specifications in the form of executable functions that conform to the Ethereum execution layer specification style are generated through an automatic construction method based on a large language model.

[0019] The candidate executable behavior specifications include: opcode stack processing behavior, resource consumption rules, semantic execution rules, and program counter update rules.

[0020] ii. Generate a set of test input parameters based on the input constraints of the candidate executable behavior specifications; construct matching test cases and initial execution contexts on the candidate executable behavior specification side and the target execution environment side using the generated parameters; generate more test cases through control flow graph expansion and parameter and context boundary mutation to cover more paths and improve the ability to detect anomalies and boundary behaviors.

[0021] The aforementioned test refers to: verifying the consistency between the candidate executable behavior specification and the target environment execution behavior; executing test cases on the candidate executable behavior specification side and the target execution environment side under the same input parameters and the same initial execution context, and comparing virtual machine state changes to determine whether there are any differences.

[0022] The initial execution context includes at least one of the following: virtual machine stack state, memory state, storage state, program counter state, and initial resource values.

[0023] When comparing virtual machine state changes, the virtual machine state change information includes at least one of the following: virtual machine stack state, memory or storage state, program counter state, resource quantity state, and consumed resource quantity.

[0024] The aforementioned correction refers to: comparing and analyzing the virtual machine state transition results before and after the execution of test cases between the candidate executable behavior specification and the target execution environment, and identifying the first instance of inconsistency in state transition results as a difference localization point, which is used to locate the execution semantics or resource consumption rules in the candidate executable behavior specification that are inconsistent with the target execution environment; and correcting the candidate executable behavior specification based on the differences to obtain the executable behavior specification of the opcode in the target execution environment.

[0025] Preferably, the consistency verification process is terminated when any of the following termination conditions are met: no state transition result difference is detected, the number of state transition differences is less than a preset threshold, or the maximum correction round is reached.

[0026] The online phase specifically includes:

[0027] Step a: Obtain the compiled bytecode of the target smart contract, disassemble the bytecode to obtain the corresponding virtual machine opcode sequence, and divide the bytecode into basic blocks based on the opcode sequence to construct a control flow graph describing the opcode execution path. Then, perform reachability analysis on the opcode sequence based on the control flow graph to determine the opcodes that may be executed on at least one reachable execution path. On this basis, screen out key opcodes that are related to changes in the Ethereum virtual machine implementation or differences in the execution environment implementation, and extract the corresponding opcode facts for the key opcodes to record the positional characteristics of the opcodes in the bytecode.

[0028] The key opcodes include: opcodes that are added, deleted, or whose execution semantics change during Ethereum Virtual Machine protocol upgrades, as well as opcodes whose execution behavior changes in the target execution environment compared to the analysis benchmark execution environment.

[0029] The opcode facts include the offset position of the opcode in the bytecode and the basic block identifier information to which the opcode belongs.

[0030] Step b: For the opcode facts, retrieve the executable behavior specifications that represent the opcode behavior in the analysis benchmark execution environment and the target execution environment respectively, in order to determine whether the opcode is supported in different execution environments and whether the execution behavior is consistent;

[0031] The opcode behavior includes: state transition rules for describing virtual machine state changes during opcode execution, and resource consumption rules for describing resource consumption during opcode execution.

[0032] The aforementioned retrieval process determines that the opcode is not supported in the target execution environment if no opcode behavior entity corresponding to the target opcode is found under the target execution environment entity, or if the supporting field of the associated opcode behavior entity is not supported.

[0033] When analyzing the same opcode associated with different opcode behavior entities in the baseline execution environment and the target execution environment, the nearest common ancestor behavior entity of the two opcode behavior entities is determined by backtracking along the "behavior entity - modification entity - behavior entity" relationship link between the opcode behavior entities in the graph structure. Combined with the opcode behavior modification entities pointing to the two opcode behavior entities, the specific modification source that caused the difference in opcode behavior is determined.

[0034] Step c: Combine the executable behavior specifications retrieved in step b to further classify the difference categories.

[0035] The categories of differences include:

[0036] a) The opcode is not supported in the target execution environment;

[0037] b) The execution semantics of the opcodes differ between the target execution environment and the analysis baseline execution environment;

[0038] c) The resource consumption rules of opcodes in the target execution environment differ from those in the analysis benchmark execution environment.

[0039] Step d: Based on the difference categories, generate execution compatibility analysis results for the smart contract in the target execution environment.

[0040] The execution compatibility analysis results include: difference categories, source information corresponding to the differences, and the source information may include the following: the offset position of the opcode fact in the smart contract bytecode, the basic block identifier of the opcode fact in the control flow graph, the executable behavior specification of the opcode behavior entity corresponding to the opcode in the execution semantic structured representation model, and opcode behavior modification information used to describe the source of execution behavior differences, so as to support the traceable verification and visualization of the execution compatibility analysis results.

[0041] Technical effect

[0042] This invention constructs a structured representation model of Ethereum execution semantics. Through environmental evolution, it uniformly models the execution behavior of opcodes in different EVM-compatible execution environments. It characterizes the semantic differences of the same opcode across different execution environments using opcode behavior entities and behavioral differences, avoiding the complexity of manually reviewing multiple technical documents or underlying implementation code. This invention combines opcode executable behavior specifications to clearly compare the differences of opcodes in different environments. Using a large model, it intelligently generates executable behavior specifications and simultaneously constructs corresponding test cases for both the executable behavior specification side and the target environment side. It automatically generates, verifies, and corrects missing executable behavior specifications, clarifying the differences of opcodes in different environments for smart contract developers. Compared to existing technologies, this invention can systematically analyze the executability and semantic consistency of smart contract opcodes across different Ethereum networks in scenarios with multiple EVM-compatible execution environments. It provides compatibility assessments for cross-chain deployment of smart contracts and demonstrates the reasons for contract behavior differences from the perspective of opcode-level behavioral differences. Attached Figure Description

[0043] Figure 1 This is a flowchart of the present invention;

[0044] Figure 2 This is a schematic diagram of the system in the embodiment;

[0045] Figure 3 An example of an executable behavior specification in the EELS style;

[0046] Figure 4 A schematic diagram illustrating entity relationship patterns for implementing a semantic structured representation model in Ethereum;

[0047] Figure 5 Flowchart of the evolution of the semantic structured representation model environment for Ethereum;

[0048] Figure 6 Flowchart for building a semantic structured representation model for Ethereum;

[0049] Figure 7 A flowchart for generating the specification of operable behavior of opcodes;

[0050] Figure 8 A flowchart for performing compatibility analysis on the target contract;

[0051] Figure 9 Generate an example of the executable behavior specification for the opcode BLOBHASH on the Linea chain;

[0052] Figure 10 This is an example of compatibility analysis for the opcode BALANCE in different execution environments. Detailed Implementation

[0053] like Figure 2 As shown in this embodiment, an execution compatibility testing system for smart contracts includes: an execution semantic structured representation model construction unit, an executable behavior specification completion unit, a bytecode parsing unit, an opcode behavior difference query unit, and an execution compatibility analysis result generation unit. Specifically: the execution semantic structured representation model construction unit extracts information from the Ethereum execution layer specification and execution environment documentation to obtain an execution semantic structured representation model; the executable behavior specification completion unit generates a complete execution semantic structured representation model based on a large model and verifies it using differential testing for missing executable behavior specifications in the execution semantic structured representation model; the bytecode parsing unit performs decompilation and control flow analysis on the input smart contract bytecode to extract key opcodes; the opcode behavior difference query unit queries the support of key opcodes in the execution environment to be compared and whether there are differences in their executable behavior specifications based on the execution semantic structured representation model; and the execution compatibility analysis result generation unit visualizes the differences in opcodes based on the query results.

[0054] like Figure 1 As shown, this embodiment illustrates the execution compatibility detection method based on the aforementioned system. In the offline phase, an Ethereum execution semantic structured representation model is constructed and maintained. The behavior of opcodes in different execution environments is uniformly modeled through executable behavior specifications. The behavior of opcodes lacking executable behavior specifications is completed and verified to form a knowledge base of opcode behavior that can be used for subsequent analysis. In the online phase, bytecode analysis is performed on the target smart contract to extract opcode facts located on key execution paths. Based on the execution semantic structured representation model, the executable behavior specifications corresponding to the opcodes in different execution environments are retrieved. The differences in their execution semantics and resource consumption rules are compared to generate the execution compatibility analysis results of the smart contract in the target execution environment.

[0055] The execution semantic structured representation model uses the Ethereum Virtual Machine's execution environment as the core modeling object and constructs corresponding opcode behavior descriptions around this execution environment. For any execution environment, a set of associated opcode behavior entities is used to characterize the specific execution characteristics of each opcode in that execution environment.

[0056] like Figure 1 As shown, the offline phase specifically includes:

[0057] Step 1: Parse and structure the execution environment specification documents, including the Ethereum execution layer specification, execution environment documents, update notes, and Ethereum improvement proposals, and initially construct a structured representation model of execution semantics.

[0058] The Ethereum Execution Layer Specification serves as the reference specification for opcode behavior. The Ethereum Execution Layer Specification describes the state transition rules during opcode execution using Python functions, thus forming an executable behavioral specification for opcode behavior. These state transition rules encompass both the opcode's update process of the virtual machine state and the corresponding resource consumption calculation process, and their form is as follows: Figure 3 As shown.

[0059] The execution environment of an Ethereum-compatible chain is uniformly defined as "an execution environment formed by introducing opcode behavior modifications based on a parent execution environment." In specific modeling, the target execution environment entity is associated with all opcode behavior entities supported by the parent execution environment. This includes opcode behavior entities that have been modified relative to the parent execution environment, as well as opcode behavior entities inherited from the parent execution environment without modification. This ensures that the execution environment has a complete set of opcode behaviors, avoids redundant descriptions of the same opcode execution specifications, and provides a unified data foundation for subsequent opcode execution difference analysis and execution compatibility assessment. Here, the parent execution environment is the direct predecessor environment of the target execution environment in the evolution relationship, used to provide inheritable executable behavior specifications. Similarly, when Ethereum's execution environment is improved through incremental updates of opcodes via Ethereum improvement proposals, the above modeling method can also be used.

[0060] To represent the evolution path of opcode execution semantics and the sources of its differences, this embodiment employs a graph-structured execution semantics representation model to store and organize execution semantic information, such as... Figure 4 As shown.

[0061] like Figure 6 As shown, step 1 specifically includes:

[0062] 1.1 Before building the map, the system preloads the standard instruction encoding mapping table of the Ethereum Virtual Machine to maintain a one-to-one correspondence between opcode byte values ​​and opcode names. The mapping table is used as the basic index structure for opcode recognition, semantic fragment matching and opcode entity construction to ensure that the same opcode involved in different document sources can be mapped to a unique opcode entity.

[0063] In the initial stage, the system reads the opcode executable behavior specifications corresponding to different main chain fork versions from the Ethereum execution layer specification and sorts the fork versions according to their version identifiers. The system selects the earliest main chain fork version with complete opcode executable behavior specifications as the root execution environment, creates a root execution environment entity, and creates a corresponding opcode behavior entity and opcode entity for each opcode based on the opcode set covered by this fork version. The system then associates the behavior entities with the root execution environment entity and the opcode entity, thereby constructing a root execution environment graph structure of the set of opcodes supported in the current root execution environment, where each opcode behavior entity is associated with its corresponding executable behavior specification.

[0064] 1.2 After completing the construction of the root execution environment, the system incrementally evolves and models the execution environments of subsequent main chain forks and each EVM-compatible chain according to the evolution order of the execution environment versions. For any target execution environment, the system first determines its parent execution environment based on the historical version identifier declared in the execution environment documentation, and establishes an evolution relationship between the target execution environment entity and the parent execution environment entity to represent the inheritance path and version evolution order between execution environments.

[0065] Subsequently, the system performs text cleaning, structural standardization, and semantic segmentation on the protocol improvement proposal document and execution environment change description document corresponding to the target execution environment. The long text is split into multiple minimum semantic segments, and each semantic segment is assigned a unique segment identifier and its position range information in the original document to support subsequent change tracing and evidence location.

[0066] After the semantic fragment is generated, the system establishes a correspondence between the current version update and the related protocol improvement proposals and execution environment change items based on the version identification information in the version change documentation. This associates each semantic fragment with its respective version update batch and related proposal identifier, forming a structured mapping relationship of "version update - proposal number - semantic fragment".

[0067] For each improvement proposal or execution environment change description, the system constructs an improvement proposal entity and records the proposal number and the changes to the opcode. Then, it associates the improvement proposal entity with the corresponding execution environment entity, indicating that the execution environment has accepted the update proposed in this update.

[0068] The system further performs opcode matching processing on semantic fragments based on the instruction encoding mapping table. By identifying the opcode name or byte value appearing in the semantic fragment, the semantic fragment is mapped to the corresponding opcode entity. The system also reads the version update batch and proposal identifier associated with the semantic fragment to record the change source information for the opcode change items generated subsequently.

[0069] Based on this, the system performs rule matching on change indicators in semantic fragments. These change indicators include a predefined set of keywords such as "update," "remove," "deprecate," "introduce," and "add." The system determines the change type as "modify," "remove," or "add" based on the matching results. If no predefined keyword is matched, the default type is "modify." This generates a set of operation code change items containing "operation code identifier—change type—semantic fragment identifier—proposal number," which drives the incremental updates of subsequent operation code action entities.

[0070] 1.3 In the process of opcode behavior modeling in the target execution environment, the system first inherits the set of opcode behavior entity versions that have taken effect in the parent execution environment and initializes the set to the default execution semantic state of the target execution environment; then, it only updates the opcode behavior versions identified in the change item set to avoid repeatedly modeling opcodes that have not changed.

[0071] For opcodes with a change type of "modification," the system creates a new opcode behavior entity version in the target execution environment and assigns it a new behavior version identifier. The new behavior entity is associated with at least its corresponding opcode identifier, supported attributes, executable behavior specification reference, and natural language semantic summary field. If the executable behavior specification of the new behavior entity is consistent with the old behavior entity, the modification is abandoned. The system removes the effective association between the target execution environment and the old behavior version in the parent execution environment, and establishes an effective association between the target execution environment entity and the new behavior version, thereby achieving version coverage of the parent execution semantics while retaining the old behavior version entity to support historical semantic backtracking.

[0072] For opcodes with a change type of "removal", the system also creates a new opcode behavior entity version in the target execution environment and marks its supported attributes as "not supported" to explicitly represent the non-executable state of the opcode in the target execution environment, without deleting the historical behavior entity in the parent execution environment, thereby ensuring the integrity of the execution semantic evolution chain.

[0073] For modifications of type "new", the system creates a new opcode entity and an opcode behavior entity, associates the opcode entity with the opcode behavior entity, and associates the opcode behavior entity with the target execution environment entity.

[0074] Specifically: If the operable behavior specification for the opcode exists, it can be read from the Ethereum execution layer specification based on the opcode identifier and version identifier. If it does not exist, the operable behavior specification generation process will be carried out, as detailed below.

[0075] To record the evolution path of execution behavior and the source of its changes, the system further constructs an opcode behavior modification entity for each modified opcode. This entity is used to associate the opcode behavior entity versions before and after the modification, and records the opcode identifier and the new and old opcode behavior identifiers. The system uses relationships to point the modification entity to the old behavior version in the parent execution environment and the new behavior version in the target execution environment, thus forming a traceable evolutionary link in the graph structure: "Old behavior entity—Behavior modification entity—New behavior entity," which supports the location of execution semantic differences and version tracking. In addition, the modification entity also establishes a relationship with the improvement proposal entity involved in this update, serving as an explanation of the source of the change.

[0076] 1.4 After completing the writing of entities and relations, the system performs consistency and integrity checks on the graph structure to ensure that each execution environment and each opcode has at most one effective opcode behavior version association, and that each behavior modification entity is associated with at least one modification proposal entity and the preceding and following behavior version entities. Through the above incremental evolution modeling mechanism based on version evolution order, the system creates new version entities only for opcode behaviors that have changed, while retaining historical execution semantic information, thereby constructing an execution semantic structured representation model that supports execution semantic inheritance, difference location, and evolution backtracking.

[0077] Step 2: Complete the execution semantic structured representation model, detect opcode behaviors that lack executable behavior specifications in the execution semantic structured representation model, read the executable behavior specifications in the old behavior entities on the evolution chain of the opcode behavior entity, as well as the modification proposals of the opcode behavior modification entity links, read the callable functions from the Ethereum execution layer specification, and generate, detect and correct the executable behavior specifications of the opcode behavior entity.

[0078] If the executable behavior specification for a new opcode behavior entity already exists, then the existing executable behavior specification will be directly adopted. This specification primarily originates from the opcode executable behavior specifications already modeled in EELS. If it does not exist, for example, if the relevant updates have been implemented in the Ethereum client but the executable behavior specification has not yet been provided, or if there are differentiated opcode behaviors in the compatible chain, then a large-model-based construction method will be used to constrain and generate its Python-form executable opcode behavior specification, such as... Figure 7 As shown.

[0079] Step 2 specifically includes:

[0080] 2.1 By constructing prompt words, the baseline execution specification, list of callable functions, protocol improvement proposals, or descriptions of execution behavior differences in the parent execution environment corresponding to the opcode are taken as input information. The large language model is then guided to generate candidate executable behavior specifications that satisfy a preset specification template through instruction constraints. The template includes function signatures and specification fragments organized by semantic blocks. These semantic blocks include stack operation blocks, resource consumption blocks, state update blocks, and program counter update blocks, serving as descriptions of candidate executable behavior specifications in the target execution environment.

[0081] 2.2 To constrain the consistency of execution behavior between candidate executable behavior specifications and the target execution environment, this embodiment introduces a verification mechanism based on execution behavior alignment. By comparing and analyzing the execution results of the target opcode in the candidate executable behavior specifications and the target execution environment under consistent test case semantics and consistent execution context, the execution rules in the candidate executable behavior specifications that are inconsistent with the target execution environment are identified, and the candidate executable behavior specifications are corrected accordingly.

[0082] During implementation, before execution, the system sequentially performs test input parameter construction, seed generator generation, path coverage expansion, and parameter mutation steps based on candidate executable behavior specifications and a large language model to form a set of test cases for consistency verification.

[0083] Specifically, firstly, based on the input constraints and execution preconditions defined in the candidate executable behavior specification, a large language model is input to construct a set of test input parameters to drive the execution of the target opcode. This set of test input parameters ensures that the opcode semantics and invocation constraints are satisfied, guaranteeing consistent input conditions between the specification and the environment.

[0084] After determining the set of test input parameters, a seed generator corresponding to the test input parameter set is further constructed using a large language model. Each seed generator receives the test input parameters and generates:

[0085] First, specification-side test cases used to drive the execution of candidate executable behavior specifications;

[0086] Secondly, target environment-side test cases used to drive the target execution environment to execute the target opcode.

[0087] This ensures that the test cases on both sides are consistent in terms of input parameters.

[0088] The test cases on the specification side are constructed in the form of a call sequence. The call sequence includes a parameter preparation call sequence for constructing a parameter that satisfies the execution constraints, and a behavior call sequence for triggering the execution of the executable behavior specification corresponding to the target opcode, thereby forming a semantically valid execution path on the candidate executable behavior specification side.

[0089] The environment-side test cases are constructed in the form of minimized bytecode fragments. The minimized bytecode fragments include a parameter preparation instruction sequence for preparing valid parameters before the target opcode, and a trigger instruction sequence for triggering the execution of the target opcode, so that the target execution environment can enter and execute the target opcode under the normal execution path.

[0090] To improve the coverage of consistency verification under different execution path conditions, the system analyzes the control flow structure of candidate executable behavior specifications, constructs the corresponding inter-process control flow representation structure, and uses a large language model to combine and expand the test input parameters and seed generator based on this structure to generate test cases that can trigger different control paths.

[0091] Based on path coverage expansion, the system performs boundary value mutation or random mutation on the generated test input parameters while satisfying the opcode executable constraint, and generates more test cases through the existing seed generator to enhance the detection capability of abnormal paths and boundary behaviors.

[0092] After the test cases are generated, the system constructs a matching initial execution context for the specification side and the environment side based on the test input parameter set, and ensures that both sides use consistent execution context conditions to avoid unexpected deviations due to context differences.

[0093] Under the same test input parameters and the same initial execution context, the system executes the candidate executable behavior specification and the target opcode in the target execution environment respectively, and performs alignment comparison on the state transition results generated during execution to determine whether the execution behaviors on both sides are consistent. During the execution comparison analysis, under the conditions of consistent test case semantics and consistent execution context, the system executes the candidate executable behavior specification and the target opcode in the target execution environment respectively, and records the virtual machine state change information before and after the opcode execution; the virtual machine state change information includes state characteristics such as virtual machine stack state, memory state, remaining resource amount, and resource consumption.

[0094] 2.3 By comparing and analyzing the state transition results of the specification side and the environment side before and after the execution of the target opcode, the first occurrence of inconsistent state transitions is identified, and this situation is identified as the basis for difference localization, which is used to identify execution semantics or resource consumption rules in the candidate executable behavior specification that are inconsistent with the target execution environment.

[0095] When an inconsistency is detected between the execution behavior of a candidate executable behavior specification and the target execution environment, the difference information is fed back to the large language model as a constraint to correct the state transition rules or resource consumption rules in the candidate executable behavior specification, thereby obtaining an opcode executable behavior specification that is consistent with the execution behavior of the target execution environment.

[0096] The test terminates when no state transition result difference is detected, the number of state transition differences is below a preset threshold, or the maximum correction round is reached. If the test passes, the executable behavior specification is written into the opcode behavior entity; if the test fails, it is logged.

[0097] like Figure 2 As shown, the online phase specifically includes:

[0098] Step a: Input the benchmark execution environment, the target execution environment, and the target Ethereum smart contract to be tested. For the input target Ethereum smart contract to be tested, perform disassembly and control flow analysis to obtain key opcodes, specifically including:

[0099] like Figure 8 As shown, the compiled bytecode of the target Ethereum smart contract is disassembled to obtain the virtual machine opcode sequence, and basic blocks are partitioned based on the opcode sequence to construct a control flow graph. The control flow graph is a directed graph, where each node represents a basic block and each edge represents a possible transition path of the control flow.

[0100] Reachability analysis is performed on the opcode sequence based on the control flow graph to identify critical opcodes located on at least one reachable execution path. Opcode facts are then extracted from the bytecode using reachable opcodes as the analysis object. These opcode facts characterize the offset position of the corresponding opcode within the bytecode and its associated basic block identifier. Critical opcodes refer to those modified, added, or altered by Ethereum compatible chains during Ethereum Virtual Machine updates, potentially causing incompatibility risks. These include opcodes such as SELFDESTRUCT, PUSH0, SLOAD, and SSTORE. Other semantically simple and stable opcodes, such as ADD, SUB, and LT, are excluded from the comparison. This process of removing unreachable codes and filtering critical opcodes reduces the scope and scale of the system comparison. The positional characteristics and execution path context of the opcodes are recorded for easy tracing during analysis.

[0101] Step b, based on the key opcodes obtained in step a, queries the supportability and executable behavior specifications of the key opcodes in the input benchmark execution environment and the target execution environment from the execution semantic structured representation model constructed in the offline environment. Specifically, this includes:

[0102] For the opcode fact to be analyzed, the opcode behavior description corresponding to the opcode is obtained in the analysis benchmark execution environment and the target execution environment, respectively, so as to determine the execution difference information of the opcode in different execution environments.

[0103] The opcode behavior description is obtained through entity relationships in a graph structure. Specifically, a graph search is used to retrieve the association links between execution environment entities and opcode entities to determine the behavior of the opcode in the corresponding execution environment. Since this embodiment models the execution behavior of the opcode in a specific execution environment as an independent opcode behavior entity, for any execution environment, the execution environment entity and the opcode entity are not directly associated, but rather indirectly associated through the opcode behavior entity corresponding to the opcode entity. This allows the differences in opcode behavior in different execution environments to be distinguished through different opcode behavior entities.

[0104] Furthermore, the following typical situations exist during the comparative analysis process.

[0105] In the first scenario, if the baseline execution environment and the target execution environment are both associated with the same opcode behavior entity in the graph structure, it indicates that the opcode behaves consistently in both execution environments, and there is no compatibility risk caused by differences in execution semantics.

[0106] In the second scenario, if a valid link from the target execution environment entity to the opcode entity cannot be found in the target execution environment, or if a link exists but the support field of the opcode behavior entity is set to "not supported", it indicates that the opcode is not supported in the target execution environment, thus determining that there is an incompatibility risk in the target execution environment.

[0107] In the third scenario, if both the baseline execution environment and the target execution environment can retrieve the associated links to the opcode entity, but they are associated with different opcode behavior entities, it indicates that although the opcode is supported in the target execution environment, its execution semantics have changed compared to the baseline execution environment, which may lead to differences in execution results or boundary conditions, thus creating a risk of semantic change.

[0108] To trace the source of differences in semantic change risks, the system uses the corresponding opcode behavior entities in the analysis benchmark execution environment and the target execution environment as the starting point for backtracking. It then backtracks along the "behavior entity—modification entity—behavior entity" association link to determine the nearest common ancestor behavior entity reachable along the modification entity link. The system also records the set of opcode behavior modification entities traversed from the ancestor behavior entity to the corresponding opcode behavior entity. For example... Figure 5In this context, if the lowest common ancestor of opcode behavior 1 and opcode behavior 2 is opcode behavior 1, then the set of opcode behavior modification entities is the set of opcode behavior modification entities between the two. By comparing the sets of opcode behavior modification entities on the two links, the source of modification leading to the difference in opcode behavior can be determined, thereby obtaining traceable execution difference explanation information, which can be used for subsequent compatibility prompts, risk identification, or difference report generation.

[0109] Furthermore, for each difference in opcode behavior identified during the execution environment compatibility analysis, the system associates a corresponding evidence citation identifier with the difference result to form a verifiable and traceable expression of the difference analysis results.

[0110] The results of the environment compatibility analysis are output in a structured format, including the following:

[0111] Opcode identifiers that exhibit different execution behaviors;

[0112] The offset position of the opcode in the target smart contract bytecode or the identifier of the underlying block;

[0113] The executable behavior specification of the opcode in the analysis benchmark execution environment;

[0114] The executable behavior specification corresponding to the opcode in the target execution environment;

[0115] And information on opcode behavior modification items or opcode behavior difference relationships used to describe the source of differences in execution behavior.

[0116] By employing the above methods, all the opcode behavior differences identified during the execution environment compatibility analysis can be traced back to their corresponding opcode facts and the source of execution semantic differences, thereby supporting the verification, review, and reproduction of the analysis results.

[0117] Step c, combining the opcodes retrieved in step b, analyzes the executable behavior specifications in the baseline and target execution environments, further classifying the differences, specifically including:

[0118] Based on predefined execution environment difference focus dimensions, the difference types corresponding to opcodes are determined during the execution environment difference analysis process. Execution environment difference focus dimensions are used to classify and characterize the differences in the execution behavior of opcodes in different execution environments, including differences in opcode support states, execution semantics, and resource consumption rules.

[0119] Among them: the opcode support state difference is used to characterize whether the target execution environment supports opcodes. When the target execution environment does not support opcodes, an execution exception will be generated during the execution of the opcode;

[0120] Execution semantic differences are used to characterize whether the state transition behavior of opcodes on the virtual machine execution state is consistent in different execution environments.

[0121] The resource consumption rule difference is used to characterize whether the resource consumption calculation method corresponding to the opcode is consistent in different execution environments, thereby determining whether the resource consumption in the actual execution process deviates from the expectation.

[0122] After the system obtains the executable behavior specifications of the same opcode in the analysis benchmark execution environment and the target execution environment, it further performs a structured comparative analysis of the two executable behavior specifications to facilitate the interpretation of specific differences in execution behavior. Specifically, the system parses each executable behavior specification into several predefined semantic blocks, used to describe the stack processing behavior of the opcode, resource consumption rules, semantic execution rules, and program counter update rules, such as... Figure 3 The two specifications are shown in the block diagram, and the two specifications are aligned and compared at the semantic block level to determine the semantic block type and content of the difference.

[0123] After completing the structured alignment comparison at the semantic block level, the system attributes the differences to predefined execution environment difference concern dimensions based on the semantic block type in which the differences occurred.

[0124] Among them: differences involving opcode support are categorized as support state differences; differences involving stack processing behavior, semantic execution rules, and program counter update rules are categorized as execution semantic differences; and differences involving resource consumption rules are categorized as resource consumption rule differences.

[0125] Step d: Based on this, the system outputs the execution environment compatibility analysis results and generates a summary explanatory text to display the analysis content based on the analysis results and their associated evidence citation identifiers.

[0126] When generating summary explanatory text, the system uses the structured difference analysis results and evidence citation identifiers as context inputs to a preset generation model. The generation model then organizes and expresses the difference analysis results in natural language. Specifically, the difference descriptions in the explanatory text are associated with the corresponding evidence citation identifiers to support reverse tracing from the explanatory text to the corresponding opcode facts and the source of their semantic differences. This reduces the risk of illusion during the generation process and improves the credibility and verifiability of the analysis results.

[0127] After practical application scenario experiments, such as Figure 9The image shows an example of generating the executable behavior specification for the opcode BLOBHASH on Linea Chain v4.4. By inputting the executable behavior specification of BLOBHASH in the parent execution environment, and the differences between Linea Chain v4.4 and the parent environment, candidate executable behavior specifications are generated through a large language model. These specifications are then verified through a testing process to obtain the final executable behavior specification. Figure 10 As shown, this is the compatibility analysis result of the opcode BALANCE in the Ethereum Istanbul and Berlin environments. By comparing the differences between semantic blocks with the same executable behavior specification, it is found that the resource consumption rules of BALANCE differ between the Istanbul and Berlin environments.

[0128] Compared with existing technologies, this invention can demonstrate the reasons for differences in contract behavior from the perspective of operational code granularity.

[0129] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A method for execution compatibility testing of smart contracts, characterized in that, In the offline phase, an Ethereum execution semantic structured representation model is constructed and maintained. The behavior of opcodes in different execution environments is uniformly modeled through executable behavior specifications. The behavior of opcodes with missing executable behavior specifications is completed and verified to form a knowledge base of opcode behavior that can be used for subsequent analysis. In the online phase, bytecode analysis is performed on the target smart contract to extract the opcode facts located on the key execution path. Based on the execution semantic structured representation model, the executable behavior specifications corresponding to the opcodes in different execution environments are retrieved. The differences in their execution semantics and resource consumption rules are compared to generate the execution compatibility analysis results of the smart contract in the target execution environment.

2. The method for execution compatibility testing of smart contracts according to claim 1, characterized in that, The offline phase specifically involves: constructing a graph-based execution semantic structured representation model to uniformly describe and manage opcode behavior in different Ethereum Virtual Machine execution environments. This model utilizes the relationship between execution environments and opcode behavior to describe the execution semantics and resource consumption behavior of opcodes in the corresponding execution environment. The target execution environment is represented as an execution environment formed by introducing opcode behavior modifications based on the parent execution environment. Based on the evolution relationship between execution environments, the unmodified opcode behavior in the parent execution environment is inherited.

3. The method for execution compatibility testing of smart contracts according to claim 1 or 2, characterized in that, The execution semantic structured representation model includes: ① Execution environment entity, which represents a specific Ethereum Virtual Machine compatible execution environment and is associated with information used to identify the execution environment version; ② Opcode entity, used to represent the opcode instruction in the virtual machine, and associated with identification information such as opcode name and byte value, so as to achieve a unique mapping of the opcode instruction during bytecode parsing; ③ Opcode behavior entity, used to represent the execution behavior characteristics of the opcode in a specific execution environment, and bound to the corresponding executable behavior specification to carry the complete execution semantics of the opcode in the target execution environment, including stack processing behavior, resource consumption rules, semantic execution rules and program counter update rules. It can also optionally be associated with natural language summary information to assist human understanding of opcode behavior; ④ Improve the proposal entity to represent a protocol improvement proposal or execution environment change description that affects the behavior of the opcode, and associate it with information such as proposal number, content summary or document fragment to support the tracing of the source of behavior change; ⑤ Opcode behavior modification entity, used to represent the changes in execution behavior introduced for a specific opcode during the evolution of the execution environment version, record the modified opcode, and record the relationship between the opcode behavior before and after the modification, so as to support the comparative analysis of the execution semantic evolution path; The relationships between entities in the execution semantic structured representation model include: establishing evolutionary relationships between execution environment entities to depict the inheritance path of the compatible chain based on the main chain fork version or its own historical version; establishing relationships between execution environment entities and opcode behavior entities to represent the opcode behavior that actually takes effect in a certain execution environment, enabling the execution environment to determine the execution semantics of each opcode through the opcode behavior entity; establishing correspondence relationships between opcode behavior entities and opcode entities to indicate the specific opcode instruction targeted by the behavior entity, realizing opcode semantic anchoring; establishing interaction relationships between opcode behavior modification entities and opcode behavior entities before and after modification to depict the behavior evolution process of the same opcode under different execution environment versions; establishing relationships between improvement proposal entities and opcode behavior modification entities to identify the opcode behavior changes introduced by specific protocol improvement proposals or execution environment change descriptions, thereby recording the source basis of behavior changes; and establishing reference relationships between execution environment entities and improvement proposal entities to support proposal aggregation retrieval and change backtracking at the execution environment version level.

4. The method for execution compatibility testing of smart contracts according to claim 3, characterized in that, When a target execution environment evolves from a parent execution environment, an evolution relationship is established between the target execution environment entity and its parent execution environment entity to represent the inheritance relationship of the target execution environment to the opcode behavior entity in the parent execution environment; In the target execution environment entity, the opcode behavior entity formed after being modified by the opcode behavior entity is associated. For opcode behavior entities that have not been modified, they are inherited by the parent execution environment entity through evolution relationship.

5. The method for execution compatibility testing of smart contracts according to claim 1, characterized in that, When the opcode behavior corresponding to the target execution environment lacks an executable behavior specification or the executable behavior specification is unavailable, an executable behavior specification is generated and tested and corrected to complete the execution semantic structured representation model. The aforementioned generation of executable behavior specifications specifically includes: i. Based on the executable behavior specification of the opcode in the parent execution environment and the opcode behavior modification information corresponding to the differences in execution behavior, generate candidate executable behavior specifications for the opcode. Specifically, based on the executable behavior specification of the corresponding opcode in the parent execution environment and the opcode behavior modification information, generate candidate executable behavior specifications in the form of executable functions that conform to the Ethereum execution layer specification style through an automatic construction method based on a large language model. The candidate executable behavior specifications include: opcode stack processing behavior, resource consumption rules, semantic execution rules, and program counter update rules; ii. Generate a set of test input parameters based on the input constraints of the candidate executable behavior specifications; construct matching test cases and initial execution contexts on the candidate executable behavior specification side and the target execution environment side using the generated parameters; generate more test cases through control flow graph expansion and parameter and context boundary mutation to cover more paths and improve the ability to detect anomalies and boundary behaviors.

6. The method for execution compatibility testing of smart contracts according to claim 5, characterized in that, The aforementioned test refers to: verifying the consistency between the candidate executable behavior specification and the target environment execution behavior; executing test cases on the candidate executable behavior specification side and the target execution environment side under the same input parameters and the same initial execution context, and comparing virtual machine state changes to determine whether there are any differences. The initial execution context includes at least one of the following: virtual machine stack state, memory state, storage state, program counter state, and initial resource values; When comparing virtual machine state changes, the virtual machine state change information includes at least one of the following: virtual machine stack state, memory or storage state, program counter state, resource quantity state, and consumed resource quantity.

7. The method for execution compatibility testing of smart contracts according to claim 5, characterized in that, The aforementioned correction refers to: comparing and analyzing the virtual machine state transition results before and after the execution of test cases between the candidate executable behavior specification and the target execution environment, and identifying the first instance of inconsistency in state transition results as a difference localization point, which is used to locate the execution semantics or resource consumption rules in the candidate executable behavior specification that are inconsistent with the target execution environment; and correcting the candidate executable behavior specification based on the differences to obtain the executable behavior specification of the opcode in the target execution environment. The consistency verification process terminates when any of the following termination conditions are met: no state transition result differences are detected, the number of state transition differences is less than a preset threshold, or the maximum correction round is reached.

8. The method for execution compatibility testing of smart contracts according to claim 1, characterized in that, The online phase specifically includes: Step a: Obtain the compiled bytecode of the target smart contract, disassemble the bytecode to obtain the corresponding virtual machine opcode sequence, and divide the bytecode into basic blocks based on the opcode sequence to construct a control flow graph describing the opcode execution path. Then, perform reachability analysis on the opcode sequence based on the control flow graph to determine the opcodes that may be executed on at least one reachable execution path. On this basis, screen out key opcodes that are related to changes in the Ethereum virtual machine implementation or differences in the execution environment implementation, and extract the corresponding opcode facts for the key opcodes to record the positional characteristics of the opcodes in the bytecode. Step b: For the opcode facts, retrieve the executable behavior specifications that represent the opcode behavior in the analysis benchmark execution environment and the target execution environment respectively, in order to determine whether the opcode is supported in different execution environments and whether the execution behavior is consistent; Step c: Based on the executable behavior specifications retrieved in step b, further classify the differences. Step d: Based on the difference categories, generate execution compatibility analysis results of the smart contract in the target execution environment; The key opcodes include: opcodes that are added, deleted, or whose execution semantics change during the Ethereum Virtual Machine protocol upgrade process, and opcodes whose execution behavior changes in the target execution environment compared to the analysis benchmark execution environment; The opcode facts include the offset position of the opcode in the bytecode and the basic block identifier information to which the opcode belongs; The categories of differences include: a) The opcode is not supported in the target execution environment; b) The execution semantics of the opcodes differ between the target execution environment and the analysis baseline execution environment; c) The resource consumption rules of the opcode in the target execution environment differ from those in the analysis benchmark execution environment; The opcode behavior includes: state transition rules for describing virtual machine state changes during opcode execution, and resource consumption rules for describing resource consumption during opcode execution; The execution compatibility analysis results include: difference categories, source information corresponding to the differences, and the source information may include the following: the offset position of the opcode fact in the smart contract bytecode, the basic block identifier of the opcode fact in the control flow graph, the executable behavior specification of the opcode behavior entity corresponding to the opcode in the execution semantic structured representation model, and opcode behavior modification information used to describe the source of execution behavior differences, so as to support the traceable verification and visualization of the execution compatibility analysis results.

9. The method for execution compatibility testing of smart contracts according to claim 8, characterized in that, The aforementioned retrieval process determines that the opcode is not supported in the target execution environment if no opcode behavior entity corresponding to the target opcode is found under the target execution environment entity or if the supporting field of the associated opcode behavior entity is not supported. When analyzing the same opcode associated with different opcode behavior entities in the baseline execution environment and the target execution environment, the nearest common ancestor behavior entity of the two opcode behavior entities is determined by backtracking along the "behavior entity - modification entity - behavior entity" relationship link between the opcode behavior entities in the graph structure. Combined with the opcode behavior modification entities pointing to the two opcode behavior entities, the specific modification source that caused the difference in opcode behavior is determined.

10. A smart contract execution compatibility testing system implementing the method of any one of claims 1-9, characterized in that, include: The system comprises four units: an execution semantic structured representation model construction unit, an executable behavior specification completion unit, a bytecode parsing unit, an opcode behavior difference query unit, and an execution compatibility analysis result generation unit. Specifically: the execution semantic structured representation model construction unit extracts and processes information from the Ethereum execution layer specification and execution environment documentation to obtain the execution semantic structured representation model; the executable behavior specification completion unit generates a complete execution semantic structured representation model based on a large model and verifies it using differential testing to identify missing executable behavior specifications in the execution semantic structured representation model; the bytecode parsing unit performs decompilation and control flow analysis on the input smart contract bytecode to extract key opcodes; the opcode behavior difference query unit queries the support of key opcodes in the execution environment to be compared and whether there are differences in their executable behavior specifications based on the execution semantic structured representation model; and the execution compatibility analysis result generation unit visualizes the differences in opcodes based on the query results.

Images