A method and system for detecting inconsistencies between solidity compilers

Abstract

This invention discloses a method and system for detecting inconsistencies between Solidity compilers, addressing the technical problem that existing Solidity compiler inconsistency detection methods lack comprehensiveness in detecting cross-compiler inconsistencies. The method includes obtaining initial seed programs, complete source code, official discrepancy documents, and corresponding executor complete source code for multiple Solidity compilers; then generating explicit and implicit code block data for each compiler and target mutation rules adapted to the initial seed programs using a large model; obtaining initial test program variants through benchmark compiler and large model repair; subsequently, fine-tuning the large model to generate target test program variants and identify inconsistent compilation and execution results; finally, combining the official discrepancy documents to generate a Solidity compiler inconsistency detection report.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method and system for detecting inconsistencies between Solidity compilers. Background Technology

[0002] In the field of compiler testing, fuzzing is often combined with program generation or mutation techniques. By automatically constructing or modifying the source program, it enables the efficient discovery of defects during the compilation and execution phases, becoming a core technical means to verify the correctness and stability of compilers. Among these, fuzzing is a mature automated testing technique that triggers potential defects in the system under test by generating massive amounts of test programs or input data.

[0003] As a programming language for smart contracts, the correctness of Solidity's compiler directly determines the compilation effect and runtime security of smart contracts. Inconsistencies between different versions and implementations of Solidity compilers can easily lead to deviations in contract compilation results, abnormal execution logic, and even smart contract security vulnerabilities.

[0004] Existing methods for detecting inconsistencies between Solidity compilers mostly focus on a single compiler, emphasizing the verification of the internal functionality of a single compiler. They are unable to comprehensively and deeply reveal potential inconsistencies such as compilation result deviations and execution logic conflicts that may occur in different versions and implementations of Solidity compilers for the same program. This results in a lack of comprehensiveness in detecting such cross-compiler inconsistencies between Solidity compilers. Summary of the Invention

[0005] This invention provides a method and system for detecting inconsistencies between Solidity compilers, which solves the technical problem that existing methods for detecting inconsistencies between Solidity compilers lack comprehensiveness in detecting such cross-compiler inconsistencies.

[0006] The first aspect of this invention provides a method for detecting inconsistencies between Solidity compilers, comprising:

[0007] Obtain the initial seed program, complete source code, and official difference documentation for multiple Solidity compilers, as well as the complete source code of the executor corresponding to each Solidity compiler.

[0008] Based on explicit and implicit boundary conditions and feature extraction prompts, a large model is used to generate explicit and implicit code block data corresponding to each Solidity compiler according to the complete source code of each Solidity compiler and the complete source code of each executor.

[0009] Based on predefined guiding rules, feature selection prompts, and mutation rule selection prompts, the large model generates target mutation rules that match each initial seed program according to the explicit and implicit code block data, complete source code, initial seed program, and complete source code of each executor corresponding to each Solidity compiler.

[0010] Based on predefined program repair prompts, a benchmark compiler and the large model are used to repair each of the initial seed programs according to multiple target mutation rules, and output multiple initial test program variants.

[0011] The large model is fine-tuned according to each initial test program variant and the corresponding target mutation rule to obtain a fine-tuned large model. Multiple target test program variants are output through the fine-tuned large model. Inconsistency identification is performed by combining each Solidity compiler and each executor. The output results are as follows: test program variants that trigger compilation inconsistency and corresponding compilation state inconsistency results and error message inconsistency results; test program variants that trigger execution inconsistency and corresponding execution state inconsistency results and execution output inconsistency results.

[0012] Based on the official difference documents of each Solidity compiler, the test program variants that trigger compilation inconsistencies and their corresponding compilation status inconsistencies and error message inconsistencies, and the test program variants that trigger execution inconsistencies and their corresponding execution status inconsistencies and execution output inconsistencies, an inconsistency detection report between Solidity compilers is generated.

[0013] Optionally, the explicit and implicit boundary conditions include explicit boundary conditions and implicit boundary conditions; the explicit and implicit code block data includes explicit code blocks, implicit code blocks, explicit code block language features, and implicit code block language features; the step of generating explicit and implicit code block data corresponding to each Solidity compiler using a large model based on the explicit and implicit boundary conditions and feature extraction prompts, according to the complete source code of each Solidity compiler and the complete source code of each executor, includes:

[0014] Explicit boundary conditions are used to identify fixed identifiers in the complete source code of each Solidity compiler and its corresponding executor, and the explicit code block corresponding to each Solidity compiler is output.

[0015] Based on implicit boundary conditions, the complete source code of each Solidity compiler and its corresponding executor is input into the large model for implicit anomaly identification, and the implicit code block corresponding to each Solidity compiler is output.

[0016] Based on the feature extraction prompts, the explicit and implicit code blocks corresponding to each Solidity compiler are input into the large model for feature analysis, and the explicit and implicit code block language features corresponding to each Solidity compiler are output.

[0017] Optionally, the predefined guidance rules include syntax guidance rules and boundary guidance rules; the selection of guidance rules based on the predefined guidance rules, feature selection prompts, and mutation rule selection prompts, using the large model to generate target mutation rules matching each initial seed program based on the explicit and implicit code block data, complete source code, initial seed program, and complete source code of each executor corresponding to each Solidity compiler, including:

[0018] Syntax-oriented prompt words are generated based on syntax-oriented rules, and the explicit and implicit code block language features corresponding to each Solidity compiler are input into the large model to output syntax-oriented mutation rules.

[0019] Boundary-oriented prompts are generated based on boundary-oriented rules. The target source code fragments from the complete source code of each Solidity compiler and its corresponding executor, the explicit code blocks, implicit code blocks, explicit code block language features, and implicit code block language features corresponding to each Solidity compiler, as well as the syntax-oriented mutation rules, are input into the large model, and boundary-oriented mutation rules are output.

[0020] Based on the feature selection prompts, the explicit code block language features and implicit code block language features corresponding to each initial seed program and each Solidity compiler are input into the large model, and the target language features matching each initial seed program are output.

[0021] Based on the mutation rules, select prompt words, input each initial seed program, the syntax-guided mutation rule, and the boundary-guided mutation rule into the large model, and output the target mutation rule that matches each initial seed program.

[0022] Optionally, based on predefined program repair prompts, a benchmark compiler and the large model are used to perform program repair on each of the initial seed programs according to multiple target mutation rules, outputting multiple initial test program variants, including:

[0023] Based on the target mutation rules, the corresponding initial seed program is mutated to output multiple mutated Solidity programs.

[0024] Each of the modified Solidity programs is input into the benchmark compiler for compilation and verification, and the error information corresponding to each of the modified Solidity programs is obtained.

[0025] Based on the predefined program repair prompts, each of the mutated Solidity programs and the corresponding error messages are input into the large model, and multiple initial test program variants are output.

[0026] Optionally, the step of fine-tuning the large model according to each initial test program variant and the corresponding target mutation rule to obtain a fine-tuned large model, and outputting multiple target test program variants through the fine-tuned large model, combining each Solidity compiler and each executor to perform inconsistency identification, and outputting test program variants that trigger compilation inconsistencies and their corresponding compilation state inconsistencies and error message inconsistencies, as well as test program variants that trigger execution inconsistencies and their corresponding execution state inconsistencies and execution output inconsistencies, includes:

[0027] Calculate the reward score for each of the initial test program variants based on the inconsistency detection results.

[0028] A fine-tuning dataset is constructed using the various initial test program variants and their corresponding reward scores and target mutation rules as samples.

[0029] The large model is fine-tuned based on the fine-tuning dataset, and the fine-tuned large model is output.

[0030] The finely tuned large model is used to generate target test program variants corresponding to each initial seed program according to each initial seed program and the corresponding target mutation rules;

[0031] Each of the target test program variants is input into the corresponding Solidity compiler for compilation, resulting in multiple compilation output results corresponding to each of the target test program variants.

[0032] Compare the compilation output results corresponding to each of the target test program variants, identify and output the test program variants that trigger compilation inconsistencies and the corresponding inconsistent compilation status results and inconsistent error messages;

[0033] Extract the bytecode generated by each of the target test program variants in each of the Solidity compilers, and input the multiple bytecodes corresponding to each of the target test program variants into the corresponding executors for execution, thereby obtaining the multiple executor output results corresponding to each of the target test program variants;

[0034] The output results of multiple executors corresponding to each of the target test program variants are processed for format adaptation to obtain multiple adapted executor output results corresponding to each of the target test program variants;

[0035] By comparing the output results of multiple adapted executors corresponding to each of the target test program variants, the test program variants that trigger execution inconsistencies and the corresponding execution state inconsistencies and execution output inconsistencies are identified and output.

[0036] Optionally, the step of generating an inconsistency detection report between Solidity compilers based on the official difference documents of each Solidity compiler, the test program variants that trigger compilation inconsistencies and their corresponding compilation state inconsistencies and error message inconsistencies, and the test program variants that trigger execution inconsistencies and their corresponding execution state inconsistencies and execution output inconsistencies, includes:

[0037] False positive elimination rules are constructed based on Solidity code snippets from the official diff documentation for each Solidity compiler.

[0038] The test program variants that trigger compilation inconsistencies and execution inconsistencies are matched with the false positive elimination rules, and test program variants that do not match are retained as having inconsistencies.

[0039] Based on the inconsistencies in the test program variants and the corresponding inconsistent execution state and output results, as well as the inconsistent compilation state and error messages, a final Solidity compiler inconsistency detection report is generated.

[0040] A second aspect of the present invention provides a system for detecting inconsistencies between Solidity compilers, comprising:

[0041] The acquisition module is used to acquire the initial seed program, complete source code, and official difference documentation for multiple Solidity compilers, as well as the complete source code of the executor corresponding to each Solidity compiler.

[0042] The first generation module is used to generate explicit and implicit code block data corresponding to each Solidity compiler based on explicit and implicit boundary conditions and feature extraction prompts, using a large model according to the complete source code of each Solidity compiler and the complete source code of each executor.

[0043] The second generation module is used to select prompts based on predefined guidance rules, feature selection prompts, and mutation rule selection prompts. It uses the large model to generate target mutation rules that match each of the initial seed programs according to the explicit and implicit code block data, complete source code, initial seed program, and complete source code of each of the Solidity compilers.

[0044] The output module is used to repair each of the initial seed programs based on predefined program repair prompts, using a benchmark compiler and the large model according to multiple target mutation rules, and output multiple initial test program variants.

[0045] The identification module is used to fine-tune the large model according to each initial test program variant and the corresponding target mutation rule to obtain the fine-tuned large model, and output multiple target test program variants through the fine-tuned large model. It also performs inconsistency identification by combining each Solidity compiler and each executor, and outputs test program variants that trigger compilation inconsistencies and their corresponding compilation status inconsistencies and error information inconsistencies, as well as test program variants that trigger execution inconsistencies and their corresponding execution status inconsistencies and execution output inconsistencies.

[0046] The false positive elimination module is used to generate an inconsistency detection report between Solidity compilers based on the official difference documents of each Solidity compiler, the test program variant that triggers the compilation inconsistency and the corresponding compilation status inconsistency results and error information inconsistency results, and the test program variant that triggers the execution inconsistency and the corresponding execution status inconsistency results and execution output inconsistency results.

[0047] A third aspect of the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the inconsistency detection method between Solidity compilers as described above.

[0048] The fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed, implements the inconsistency detection method between Solidity compilers as described above.

[0049] The fifth aspect of the present invention provides a computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions, wherein, when the program instructions are executed by a computer, the computer performs the steps of the inconsistency detection method between Solidity compilers as described above.

[0050] As can be seen from the above technical solutions, the present invention has the following advantages:

[0051] The above-described technical solution of the present invention provides a method for detecting inconsistencies between Solidity compilers. This method acquires the initial seed programs, complete source code, and official discrepancy documents of multiple Solidity compilers, as well as the complete source code of the executors corresponding to each Solidity compiler. Based on explicit and implicit boundary conditions and feature extraction prompts, a large model is used to generate explicit and implicit code block data corresponding to each Solidity compiler based on the complete source code of each Solidity compiler and the complete source code of each executor. Based on predefined guidance rules, feature selection prompts, and mutation rule selection prompts, the large model is used to generate target mutation rules matching each initial seed program based on the explicit and implicit code block data, complete source code, initial seed programs, and the complete source code of each executor. Based on predefined program repair prompts, a benchmark compiler and the large model are used to repair each initial seed program according to multiple target mutation rules, outputting multiple initial test program variants. The large model is then fine-tuned based on each initial test program variant and the corresponding target mutation rules to obtain the fine-tuned version. The large model is then used, and multiple target test program variants are output through fine-tuning of the large model. Inconsistency identification is performed by combining each Solidity compiler and each executor, outputting test program variants that trigger compilation inconsistencies and their corresponding compilation state inconsistencies and error messages, as well as test program variants that trigger execution inconsistencies and their corresponding execution state inconsistencies and execution output inconsistencies. Based on the official difference documents of each Solidity compiler, the test program variants that trigger compilation inconsistencies and their corresponding compilation state inconsistencies and error messages, and the test program variants that trigger execution inconsistencies and their corresponding execution state inconsistencies and execution output inconsistencies, a Solidity compiler inconsistency detection report is generated. Based on the above scheme, this invention compiles and executes the initial seed program on multiple Solidity compilers and their corresponding executors, and performs semantic alignment and differential analysis on different output results, effectively identifying multiple types of compiler inconsistencies, thereby improving the comprehensiveness of cross-compiler inconsistency defect detection between Solidity compilers. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a flowchart illustrating the steps of a method for detecting inconsistencies between Solidity compilers according to Embodiment 1 of the present invention.

[0054] Figure 2 This is a schematic diagram of a compiler source code example containing boundary conditions provided in Embodiment 1 of the present invention;

[0055] Figure 3 This is a schematic diagram of the mutation rule generation framework provided in Embodiment 1 of the present invention;

[0056] Figure 4 This is a schematic diagram of prompt words for generating grammar-guided rules provided in Embodiment 1 of the present invention;

[0057] Figure 5 This is a schematic diagram of the prompt words for boundary-oriented rule generation provided in Embodiment 1 of the present invention;

[0058] Figure 6 This is a schematic diagram of the prompt words for feature selection and mutation rule selection provided in Embodiment 1 of the present invention;

[0059] Figure 7 This is a schematic diagram of the prompt words for program mutation and repair provided in Embodiment 1 of the present invention;

[0060] Figure 8 This is an overall framework diagram of an inconsistency detection method between Solidity compilers provided in Embodiment 1 of the present invention;

[0061] Figure 9 This is a structural block diagram of an inconsistency detection system between Solidity compilers provided in Embodiment 2 of the present invention. Detailed Implementation

[0062] This invention provides a method and system for detecting inconsistencies between Solidity compilers, which solves the technical problem that existing methods for detecting inconsistencies between Solidity compilers lack comprehensiveness in detecting such cross-compiler inconsistencies.

[0063] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. It should be noted that in the optional embodiments of the present invention, the object information and other related data involved require the permission or consent of the object when the embodiments of the present invention are applied to specific products or technologies, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. That is to say, if the embodiments of the present invention involve data related to the object, it needs to be obtained with the authorization and consent of the object, the authorization and consent of the relevant departments, and in compliance with the relevant laws, regulations, and standards of the country and region. If personal information is involved in the embodiments, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required, and the embodiments also need to be implemented with the authorization and consent of the object.

[0064] Terminology Explanation:

[0065] 1. A Solidity compiler is a compiler used to perform syntax analysis, semantic analysis, code generation, and optimization on Solidity programs, and to generate bytecode that can run in a virtual machine. The bytecode is executed by the virtual machine to implement the corresponding smart contract logic.

[0066] 2. Cross-Solidity compiler differences refer to situations where the same Solidity program, processed by different Solidity compilers, produces different results or behaviors. These differences include both variations in the results generated during the compilation phase and variations in the behavior exhibited by the generated bytecode during execution in the virtual machine. These differences can be categorized into the following four typical scenarios:

[0067] (1) Inconsistent error messages, that is, when different Solidity compilers determine that the program cannot be compiled, the error messages output may differ in terms of error location, cause description or level of detail;

[0068] (2) Inconsistent compilation status, that is, for the same Solidity program, at least one Solidity compiler can successfully complete the compilation and generate bytecode, while at least another Solidity compiler reports an error during the compilation stage;

[0069] (3) Inconsistent execution state, that is, when bytecode generated by different Solidity compilers is executed in the virtual machine, at least one bytecode can be executed normally, while at least another bytecode will encounter an exception, be aborted or rollback during execution;

[0070] (4) Inconsistent execution results, that is, the bytecode generated by different Solidity compilers can all be executed normally, but their execution output results or the resulting state changes are different.

[0071] This invention targets the following Solidity compilers: Solc, Solang, Revive, Sold, Solar, and Zksolc. Solc is the first Solidity compiler on the market. When making comparisons, Solc will be used as the benchmark.

[0072] Please see Figure 1 , Figure 1 This is a flowchart illustrating the steps of a method for detecting inconsistencies between Solidity compilers, as provided in Embodiment 1 of the present invention.

[0073] This invention provides a method for detecting inconsistencies between Solidity compilers, comprising:

[0074] Step 101: Obtain the initial seed program, complete source code, and official difference documentation for multiple Solidity compilers, as well as the complete source code of the executor corresponding to each Solidity compiler.

[0075] The initial seed program refers to the basic test program that conforms to the Solidity syntax specification and can be used as the starting point for mutation processing. It is the original input for generating various test program variants.

[0076] Complete source code refers to all the code files of multiple Solidity compilers themselves, as well as all the code files of the executors that come with each Solidity compiler. It is the key basis for extracting compiler and executor features and generating explicit and implicit code block data.

[0077] Official difference documentation refers to the formal documentation released by the compiler developers to explain the differences between different Solidity compilers in terms of syntax processing logic, compilation output standards, execution mechanism adaptation, etc. It is an important reference for subsequent build false positive elimination rules.

[0078] Step 102: Based on explicit and implicit boundary conditions and feature extraction prompts, a large model is used to generate explicit and implicit code block data corresponding to each Solidity compiler based on the complete source code of each Solidity compiler and the complete source code of each executor.

[0079] Explicit and implicit boundary conditions include explicit boundary conditions and implicit boundary conditions.

[0080] Explicit and implicit code block data includes explicit code blocks, implicit code blocks, explicit code block language features, and implicit code block language features.

[0081] It should be noted that, based on explicit and implicit boundary conditions and feature extraction prompts, and combined with the complete source code of each Solidity compiler and its corresponding executor obtained in the preceding steps, the source code characteristics of different compilers are analyzed in a targeted manner through a large model, and explicit and implicit code block data specific to each Solidity compiler are accurately generated. This type of data can fully carry the core characteristics of the compiler and executor, and becomes the key foundation for building adaptive target mutation rules for the initial seed program.

[0082] Furthermore, step 102 may include the following sub-steps:

[0083] S21. Use explicit boundary conditions to identify fixed identifiers for the complete source code of each Solidity compiler and its corresponding executor, and output the explicit code block corresponding to each Solidity compiler.

[0084] S22. Based on implicit boundary conditions, input the complete source code of each Solidity compiler and its corresponding executor into the large model to identify implicit anomalies and output the implicit code blocks corresponding to each Solidity compiler.

[0085] S23. Based on feature extraction prompts, input the explicit and implicit code blocks corresponding to each Solidity compiler into the large model for feature analysis, and output the language features of the explicit and implicit code blocks corresponding to each Solidity compiler.

[0086] Explicit boundary conditions refer to the judgment conditions used to identify fixed identifiers from the complete source code of the Solidity compiler and its corresponding executor. They are the core basis for extracting explicit features of the compiler and executor.

[0087] Implicit boundary conditions refer to the judgment conditions used to guide large models to identify implicit exceptions in the complete source code of the Solidity compiler and its corresponding executor. They are the core basis for mining the implicit features of the compiler and executor.

[0088] It's important to note that boundary conditions can be categorized into explicit and implicit types. Explicit boundary conditions include exception and error handling, unimplemented features, code path validity checks, and assertions. These boundary conditions typically have fixed identifiers, such as "error," "panic," "unimplemented," "unreachable," or "assert." For example, Figure 2A code block containing the identifier "unimplemented" is shown. Therefore, code blocks containing these identifiers (i.e., explicit code blocks) can be extracted manually. Implicit boundary conditions (such as type conversion errors or memory overflows) are more difficult to identify manually. For these cases, this invention uses a large model to assist in extraction. Ultimately, all code blocks containing boundary conditions are obtained, namely explicit and implicit code blocks.

[0089] Furthermore, such as Figure 2 As shown, compiler source code indicates that boundary conditions are typically triggered through complex control flow. This characteristic makes it difficult for large models to directly generate programs capable of reaching these boundary conditions. Therefore, this invention first summarizes the program characteristics associated with boundary condition code blocks. Based on this, large models (i.e., artificial intelligence models, such as GPT-4, CodeLlama, and other large language models adapted to code analysis scenarios) can generate accurate mutation rules to trigger these boundary conditions. Large models are then used to directly analyze code blocks containing boundary conditions and identify the Solidity language features involved (including explicit and implicit code block language features). For example, in... Figure 3 In the large model, the program features (language features) identified include "fixed-length arrays", "structures", and "internal functions".

[0090] In this embodiment, explicit boundary conditions are used to identify fixed identifiers in the complete source code of each Solidity compiler and its corresponding executor, outputting the explicit code blocks corresponding to each Solidity compiler. Then, based on implicit boundary conditions, the complete source code of each Solidity compiler and its corresponding executor is input into a large model for implicit anomaly detection, outputting the implicit code blocks corresponding to each Solidity compiler. Next, based on feature extraction prompts, the explicit and implicit code blocks corresponding to each Solidity compiler are input into a large model for feature analysis, outputting the explicit and implicit code blocks corresponding to each Solidity compiler. The process involves identifying explicit and implicit code block language features corresponding to the Solidity compiler. First, explicit boundary conditions are used to accurately capture the explicit features of directly identifiable fixed identifiers in the source code. Then, a large model is used to mine the implicit abnormal features hidden in the source code. Finally, feature extraction prompts guide the large model to perform targeted analysis on the two types of code blocks, extracting language features that can characterize the core features of each compiler. This achieves comprehensive and hierarchical extraction of features of each Solidity compiler and executor, covering both explicit fixed features and uncovering implicit abnormal features, avoiding the feature omission problem caused by a single feature extraction method.

[0091] Step 103: Based on predefined guiding rules, feature selection prompts, and mutation rule selection prompts, the large model generates target mutation rules that match each initial seed program according to the explicit and implicit code block data, complete source code, initial seed program, and complete source code of each executor corresponding to each Solidity compiler.

[0092] Predefined guidance rules include syntax guidance rules and boundary guidance rules.

[0093] It should be noted that this step relies on the explicit and implicit code block data of each compiler extracted in the previous step, integrates multi-dimensional source code and seed program data, and guides the large model to accurately match through predefined rules and prompt words. The generated target mutation rules can be adapted to the characteristics of each initial seed program and the features of different compilers, providing the core basis for subsequent seed program mutation processing.

[0094] Furthermore, step 103 may include the following sub-steps:

[0095] S31. Generate syntax-guided prompt words based on syntax-guided rules, and input the explicit code block language features and implicit code block language features corresponding to each Solidity compiler into the large model, and output syntax-guided mutation rules;

[0096] S32. Generate boundary-oriented prompts based on boundary-oriented rules, and input the target source code fragments from the complete source code of each Solidity compiler and its corresponding executor, the explicit code blocks, implicit code blocks, explicit code block language features, implicit code block language features, and syntax-oriented mutation rules into the large model, and output the boundary-oriented mutation rules.

[0097] S33. Based on feature selection prompts, input the explicit and implicit code block language features of each initial seed program and each Solidity compiler into the large model, and output the target language features that match each initial seed program.

[0098] S34. Select prompt words based on mutation rules, input each initial seed program, syntax-guided mutation rule and boundary-guided mutation rule into the large model, and output the target mutation rule that matches each initial seed program.

[0099] Syntax-oriented rules refer to the pre-defined core principles used to guide the generation of syntax-level mutation rules, clarifying the direction in which mutation rules must conform to the characteristics of Solidity syntax and the differences in syntax processing among various compilers.

[0100] Syntax-guided prompts refer to instruction text generated based on syntax-guided rules. They are used to guide large models to focus on the explicit and implicit code block language features of each Solidity compiler and generate syntax-level variation rules.

[0101] Syntax-guided mutation rules refer to the mutation rules output by the large model based on syntax-guided prompts and the language features of explicit and implicit code blocks of each compiler. They are mainly used to perform syntax-level mutation processing on the initial seed program.

[0102] Boundary-oriented rules refer to the pre-defined core principles used to guide the generation of boundary-level mutation rules, clarifying the direction in which mutation rules should conform to the boundary characteristics and exception handling differences of each compiler and corresponding executor.

[0103] Boundary-guided prompts refer to instruction texts generated based on boundary-guided rules, used to guide large models to fuse multiple types of data (target source code fragments, explicit and implicit code blocks, and language features, etc.) and generate boundary-level mutation rules.

[0104] The target source code fragment refers to the core code fragment related to boundary characteristics and exception handling extracted from the complete source code of each Solidity compiler and its corresponding executor. It is an important input data for generating boundary-oriented mutation rules.

[0105] Boundary-oriented mutation rules refer to mutation rules for large models based on boundary-oriented prompts and outputs of multiple types of input data. They are mainly used to perform boundary-level mutation processing on the initial seed program and can specifically trigger boundary-related cross-compiler inconsistencies.

[0106] Target language features refer to the set of core language features selected by the large model from the explicit and implicit code block language features of each compiler, which match the characteristics of each initial seed program, based on feature selection prompts.

[0107] It should be noted that this step aims to generate two types of mutation rules: syntax-oriented rules and boundary-oriented rules. The process is as follows: Figure 3 First, after extracting the code blocks containing boundary conditions, the program features that can trigger these code blocks are identified, and simple mutation rules, i.e., syntax-oriented rules, are generated for each feature. Based on this, more complex mutation rules, i.e., boundary-oriented rules, are constructed by combining the identified program features and syntax-oriented rules.

[0108] Among these, syntax-guided mutation rules are generated to randomly mutate programs containing the aforementioned program characteristics. If large models are directly used to analyze boundary conditions and generate mutation rules, these rules are rather vague and cannot clearly indicate the direction of mutation. However, using syntax-guided rules as a reference ensures that the subsequently generated boundary-guided rules are more accurate.

[0109] Furthermore, Figure 4 The invention demonstrates prompts for generating grammar-guided rules. Since each language feature contains multiple variants, the first instruction in the prompt requires the large model to list all variants associated with that feature. For example, for a struct, variants include field type, visibility, and declaration position. Regarding variant actions, the invention selects five representative operation types (insertion, addition, replacement, modification, and clearing) for the large model to choose from.

[0110] Furthermore, boundary-oriented mutation rules are generated based on program features and syntax-guided rules. A single code block may contain multiple boundary conditions, and each boundary condition may be triggered in multiple ways, with each triggering method corresponding to a mutation rule. To ensure the completeness of the rules, this invention selects only one program feature and one boundary condition in each prompt. Simultaneously, to ensure the clarity of the rules, this invention utilizes syntax-guided rules as context to guide the generation of boundary-oriented rules.

[0111] in, Figure 5 Hints for generating boundary-oriented mutation rules are presented. The first task in these hints requires the large model to analyze how current boundary-related procedural features trigger specified boundary conditions; the second task requires the large model to select from existing syntax-oriented rules or synthesize new rules based on them.

[0112] It is worth noting that after obtaining all mutation rules, they also need to be categorized. This invention uses program features embedded in the prompt as labels to indicate the main category to which each generation rule belongs. These labels will be used subsequently for selecting mutation rules.

[0113] In this embodiment, syntax-guided prompts are generated based on syntax-guided rules, and the explicit and implicit code block language features corresponding to each Solidity compiler are input into the large model. The large model combines the prompts to focus on syntax-level feature analysis and outputs syntax-guided mutation rules. Subsequently, boundary-guided prompts are generated based on boundary-guided rules, and the target source code fragments from the complete source code of each Solidity compiler and its corresponding executor, the explicit and implicit code blocks corresponding to each Solidity compiler, their language features, and the syntax-guided mutation rules are all input into the large model. This guides the large model to integrate syntax features and boundary features for analysis and output boundary-guided mutation rules. Finally, based on feature selection prompts, the explicit code block language features corresponding to each initial seed program and each Solidity compiler are input into the large model. The implicit code block language features are input into the large model to filter out the core features that fit each initial seed program, and output the target language features that match each initial seed program. Finally, based on the mutation rules, prompt words are selected, and each initial seed program, syntax-oriented mutation rules, and boundary-oriented mutation rules are input into the large model. The large model combines the characteristics of the seed program with the two types of oriented mutation rules to adapt and match, and outputs the target mutation rules that match each initial seed program. This process generates syntax and boundary-oriented mutation rules in a hierarchical manner, and then combines the characteristics of the seed program to filter target features and match target mutation rules. This achieves the pertinence and comprehensiveness of mutation rule generation, which can ensure that the generated target mutation rules can not only fit the syntax and boundary features of each compiler, but also accurately adapt to the characteristics of the initial seed program. This provides high-quality rule support for the subsequent generation of test program variants that can effectively trigger cross-compiler inconsistencies.

[0114] Step 104: Based on predefined program repair prompts, use a benchmark compiler and large model to repair each initial seed program according to multiple target mutation rules, and output multiple initial test program variants.

[0115] It should be noted that, based on predefined program repair prompts, a benchmark compiler and a large model are used to repair each initial seed program according to multiple target mutation rules. First, the compilation status of the mutated seed program is verified by the benchmark compiler. Then, the large model combines the program repair prompts to repair programs with compilation errors, and finally outputs multiple initial test program variants. This step relies on the target mutation rules generated in the previous step and is processed collaboratively by the benchmark compiler and the large model to ensure that the output initial test program variants are compilable, providing an effective test carrier for subsequent cross-compiler inconsistency detection.

[0116] Furthermore, step 104 may include the following sub-steps:

[0117] S41. Based on the mutation rules of each target, the corresponding initial seed program is mutated to output multiple mutated Solidity programs.

[0118] S42. Input each mutated Solidity program into the benchmark compiler for compilation and verification, and obtain the corresponding error information for each mutated Solidity program.

[0119] S43. Based on predefined program repair prompts, input each mutated Solidity program and its corresponding error message into the large model, and output multiple initial test program variants.

[0120] It should be noted that after generating mutation rules, the first step is to select appropriate rules to mutate the program. This process can be divided into three stages: rule selection, rule application, and selection optimization. In the rule selection stage, this invention selects the most suitable mutation rule for each seed program. In the rule application stage, the selected rules are applied to the program mutation, and programs that cannot be compiled are repaired. In the selection optimization stage, reinforcement learning is used to fine-tune the large model to optimize the rule selection process.

[0121] Specifically, for the selection of mutation rules, this invention uses two types of mutation rules to perform mutation. Boundary-oriented rules aim to discover inconsistencies related to boundary conditions, while syntax-oriented rules ensure the syntactic diversity of the program, thereby triggering inconsistencies related to code blocks containing boundary conditions. Figure 6 The prompts for selecting features and mutation rules are displayed. First, the prompts help the large model identify which features the seed program contains. Figure 6 (Upper part), then select the specific mutation rule under the selected feature ( Figure 6 (Lower part). Since the mutation rules are generated based on certain characteristics that the program already possesses, this ensures that the selected rules are highly matched with the seed program.

[0122] Furthermore, Figure 7 The tutorial demonstrates the mutation and repair process. After selecting an appropriate rule, it is applied to the seed program to mutate. Figure 7 (Upper part). If the generated program cannot be compiled by Solc, error information will be provided to the larger model to fix the program. Figure 7 (See the lower part). The purpose of the fix is ​​twofold: first, programs that cannot be compiled by Solc usually cannot be compiled by other compilers either, making it difficult to detect inconsistencies; second, compilation errors are often due to complex program structures introduced by mutation rules, which large models may find difficult to handle correctly in one go. The fix helps generate inputs that are more likely to trigger inconsistencies.

[0123] In this embodiment, the initial seed program is mutated based on the target mutation rules. According to the mutation dimensions set in the rules, such as syntax and boundaries, the code structure and logical statements of the initial seed program are specifically adjusted and modified, outputting multiple mutated Solidity programs. Then, each mutated Solidity program is input into the benchmark compiler to execute the complete compilation process, verifying the compilability of the program and accurately capturing various error messages generated during compilation, obtaining the corresponding error messages for each mutated Solidity program. Next, based on predefined program repair prompts, each mutated Solidity program and its corresponding error messages are input into the large model. The large model analyzes the root cause of the error, locates the abnormal program position, and specifically corrects the errors in the code, ultimately outputting multiple initial test program variants. This process, through the step-by-step processing of "targeted mutation - compilation verification - precise repair," ensures that the output initial test program variants have good compilability and effectiveness, eliminates invalid mutated programs, avoids invalid data interfering with subsequent detection processes, and ensures that the test program variants can effectively adapt to the detection scenarios of various Solidity compilers and executors.

[0124] Step 105: Fine-tune the large model according to each initial test program variant and the corresponding target mutation rule to obtain the fine-tuned large model. Output multiple target test program variants through the fine-tuned large model. Combine each Solidity compiler and each executor to identify inconsistencies. Output the test program variants that trigger compilation inconsistencies and the corresponding compilation status inconsistencies and error message inconsistencies, as well as the test program variants that trigger execution inconsistencies and the corresponding execution status inconsistencies and execution output inconsistencies.

[0125] It should be noted that the large model is fine-tuned based on each initial test program variant and its corresponding target mutation rule. The characteristics of the initial test program variants and their corresponding target mutation rules are used as training samples to optimize the model parameters, resulting in a fine-tuned large model. This fine-tuned large model is then used to perform more precise mutation processing on the initial seed program, outputting multiple target test program variants. Subsequently, these target test program variants are compiled in various Solidity compilers and executed in their corresponding executors. The output results of different compilers and executors are compared to identify inconsistencies. Finally, the model outputs the test program variants that trigger compilation inconsistencies and their corresponding compilation state and error message inconsistencies, as well as the test program variants that trigger execution inconsistencies and their corresponding execution state and execution output inconsistencies. This step relies on the previously generated initial test program variants to complete model fine-tuning, improving the accuracy of model-generated test variants. Effective identification of cross-compiler inconsistencies is achieved through verification with multiple compilers and executors.

[0126] Furthermore, step 105 may include the following sub-steps:

[0127] S51. Calculate the reward score for each initial test procedure variant based on the inconsistency detection results.

[0128] S52. Construct a fine-tuning dataset using each initial test program variant and its corresponding reward score and target mutation rule as samples;

[0129] S53. Fine-tune the large model based on the fine-tuning dataset and output the fine-tuned large model;

[0130] S54. Using the finely tuned large model, generate target test program variants corresponding to each initial seed program based on each initial seed program and the corresponding target mutation rules.

[0131] S55. Input each target test program variant into the corresponding Solidity compiler for compilation, and obtain multiple compilation output results corresponding to each target test program variant;

[0132] S56. Compare the compilation output results corresponding to each target test program variant, identify and output the test program variant that triggers compilation inconsistency and the corresponding compilation status inconsistency results and error message inconsistency results;

[0133] S57. Extract the bytecode generated by each Solidity compiler for each target test program variant, and input the multiple bytecodes corresponding to each target test program variant into the corresponding executor for execution, and obtain the multiple executor output results corresponding to each target test program variant.

[0134] S58. Perform format adaptation processing on the multiple executor output results corresponding to each target test program variant to obtain multiple adapted executor output results corresponding to each target test program variant.

[0135] S59. Compare the output results of multiple adapted executors corresponding to each target test program variant, identify and output the test program variant that triggers execution inconsistency and the corresponding execution state inconsistency results and execution output inconsistency results.

[0136] Bytecode refers to the binary code generated by compiling the target test program variant with the Solidity compiler. It can be loaded and executed by the corresponding executor and is the core data connecting the compilation and execution stages.

[0137] It should be noted that, in order to optimize the rule selection process, this invention utilizes reinforcement learning to fine-tune the large model. Fine-tuning is performed using the GRPO algorithm (Guided Reward Policy Optimization), and the reward function is designed as follows:

[0138] The reward function calculates a score for the mutation procedure using the inconsistency detection results. This score indirectly reflects the quality of the selected mutation rule. (Reward Score) The calculation is as follows:

[0139] ;

[0140] If the new program triggers inconsistency, the score is 1; if it's a false positive, the score is deducted by -1; if the program fails to compile with Solc, the score is also deducted by -1. Otherwise, if the program compiles successfully but does not trigger inconsistency, the score is determined by the coverage difference. Decision. Coverage differences. The calculation method is as follows: Compile the program before and after mutation using Solc, measure the coverage of each version in the Solc compiler, and then calculate the difference. The coverage difference ranges from -1 to 1, which helps guide large models to generate programs with richer syntax through mutation.

[0141] Furthermore, to detect inconsistencies, the compilation and execution results of the program were compared on different compilers. Since Solc was the first Solidity compiler, and many other compilers use it as a reference, Solc was used as the comparison benchmark. The following details how the compilation and execution results were compared, and how false positives were eliminated.

[0142] Specifically, when comparing compilation results, inconsistencies include inconsistent error messages and inconsistent compilation states. Both can be detected by directly comparing the compiler output.

[0143] Inconsistent error messages occur when two compilers both generate errors, but one provides a clear error message while the other does not. A clear error message typically begins with "error," followed by the location and cause of the error. Therefore, clear error messages can be identified through keyword matching.

[0144] Inconsistent compilation states refer to situations where one compiler succeeds in compiling while another fails. This can be detected by directly comparing the compiler output: successful compilation generates bytecode, while compilation failure throws an error.

[0145] When comparing execution results, inconsistencies in execution results include inconsistencies in execution status and inconsistencies in execution output, both of which can be detected by directly comparing the executor output.

[0146] Inconsistent execution states refer to a program that can be executed after compilation by one compiler, but fails after compilation by another. If the executor generates an error, it indicates that the execution has failed; otherwise, the program executes successfully.

[0147] Inconsistent execution output refers to differences in the output of the executor on programs generated by two different compilers. This invention supports the detection of inconsistencies in execution results from four compilers (Solc, Revive, Zksolc, and Solang). Specifically, the Solang-compatible virtual machine SVM has a different output format than other virtual machines (EVM, PolkaVM, and ZKEVM). SVM outputs in Borsh format, while the other virtual machines output in ABI encoded format. The former extracts specific data using the Borsh class, while the latter uses an ABI decoder to decode the output, resulting in comparable results.

[0148] In this embodiment, based on the inconsistency detection results corresponding to each initial test program variant, and combined with core indicators such as the detected inconsistency type and quantity, the reward score corresponding to each initial test program variant is quantitatively calculated. Using each initial test program variant, its corresponding reward score, and the target mutation rule as core elements, a fine-tuning dataset is constructed according to sample association specifications. Based on this fine-tuning dataset, the GRPO algorithm is used to fine-tune the large model through reinforcement learning, optimizing the model's ability to generate test program variants and rule matching, and outputting the fine-tuned large model. Subsequently, the fine-tuned large model is used to perform targeted mutation processing in conjunction with each initial seed program and its corresponding target mutation rule, generating target test program variants corresponding to each initial seed program. Each target test program variant is input into its corresponding Solidity compiler to execute the compilation process, recording and obtaining multiple compilation output results for each target test program variant under different compilers. By comparing each compilation output result corresponding to each target test program variant, variants and result information with differences are filtered out, and test program variants that trigger compilation inconsistencies and their corresponding compilation status inconsistencies (such as some compilers compiling successfully while others fail) and error information are identified and output. Inconsistent results (such as error type and location differences) are identified. Further, bytecode files generated by compiling each target test program variant in each Solidity compiler are extracted. Multiple bytecodes corresponding to each target test program variant are input into their respective executors for execution. The output results of multiple executors for each target test program variant under different executors are recorded and obtained. The output results of multiple executors corresponding to each target test program variant are processed with unified format standardization and data adaptation to obtain multiple adapted executor output results for each target test program variant. Finally, the multiple adapted executor output results for each target test program variant are compared, and difference information is filtered. Test program variants that trigger execution inconsistencies and their corresponding execution state inconsistencies (such as some executors running successfully while others fail) and execution output inconsistencies (such as differences in return values ​​and runtime logs) are identified and output. This process uses reinforcement learning to fine-tune and optimize the performance of the large model. Combined with multi-dimensional comparison and identification throughout the "compile-execution" process, it achieves accurate capture of cross-compiler inconsistencies, improves the effectiveness of test program variants and the comprehensiveness of inconsistency identification, and effectively solves the problems of incomplete detection scenario coverage and insufficient identification accuracy in existing methods.

[0149] Step 106: Based on the official difference documentation of each Solidity compiler, the test program variants that trigger compilation inconsistencies and the corresponding inconsistent compilation status results and error messages, and the test program variants that trigger execution inconsistencies and the corresponding inconsistent execution status results and execution output results, generate an inconsistency detection report between Solidity compilers.

[0150] It should be noted that, based on the official discrepancy documents of each Solidity compiler, the test program variants that trigger compilation inconsistencies and their corresponding inconsistent compilation status results and error messages, as well as the test program variants that trigger execution inconsistencies and their corresponding inconsistent execution status results and execution output results, various inconsistency detection data are integrated and attribution analysis is completed by comparing them with the official discrepancy documents. The system systematically sorts out the inconsistency characteristics and manifestations across compilers, and finally generates an inconsistency detection report between Solidity compilers. This step serves as the final step in the entire detection process, verifying the detection results with the official documentation to form a traceable and complete detection conclusion.

[0151] Furthermore, step 106 may include the following sub-steps:

[0152] S61. Construct false positive elimination rules based on Solidity code snippets from the official difference documents of various Solidity compilers;

[0153] S62. Perform string matching between the test program variants that trigger compilation inconsistencies, the test program variants that trigger execution inconsistencies, and the false positive elimination rules, and retain the test program variants that do not match successfully and have inconsistencies.

[0154] S63. Based on the existence of inconsistent test program variants and corresponding inconsistent execution state results and inconsistent execution output results, as well as inconsistent compilation state results and inconsistent error messages, generate the final Solidity compiler inconsistency detection report.

[0155] False positive elimination rules refer to a set of rules built based on code snippets extracted from the official Solidity compiler diff documentation, which are used to filter out false positives caused by known diffs marked by the official documentation. They are the core basis for eliminating invalid variants.

[0156] Inconsistent test program variants refer to test program variants that fail to match after string matching, and are confirmed to be inconsistent due to unknown or unofficial labeling differences. They are the core data carrier for generating the final test report.

[0157] It should be noted that this step aims to eliminate false positives among detected inconsistencies. Each Solidity compiler includes detailed documentation explicitly listing its differences from Solc and explaining which syntax features are handled differently. If a syntax feature causing inconsistency is detailed in the difference documentation, clearly indicating the expected compilation or execution result, it is considered a false positive. However, if the documentation only states that a feature may cause inconsistency without specifying the details, it is still considered a valid finding, as it may reveal potential problems that developers have not noticed. Therefore, this invention manually analyzes the difference documentation to identify syntax features that explicitly specify the compilation or execution result and organizes them into corresponding Solidity code snippets. Subsequently, false positives are eliminated through string matching.

[0158] Specifically, based on the official difference documentation for each Solidity compiler, technical personnel manually analyzed the documentation line by line to accurately identify the syntactic features that explicitly specify differences in compilation or execution results. The code logic corresponding to these syntactic features was then organized into standardized Solidity code snippets. Based on these manually organized Solidity code snippets, core features corresponding to known differences were extracted. Based on this, false positive elimination rules were manually constructed to filter out false positives caused by known differences. Subsequently, the code content of test program variants that trigger compilation inconsistencies and test program variants that trigger execution inconsistencies was matched against the false positive elimination rules segment by segment. False positive variants caused by officially known differences were filtered out, and only those that did not match and were caused by unknown or non-standard differences were retained. The system identifies inconsistencies in test program variants caused by annotation differences. Based on these variants and their corresponding inconsistent execution states, outputs, compilation states, and error messages, the system systematically identifies core inconsistencies and their characteristics, generating a final Solidity compiler inconsistency detection report. This process filters false positives caused by known differences by constructing false positive elimination rules, focusing on real, unannotated cross-compiler inconsistencies, eliminating invalid false positive data in the detection results, and preventing known differences from interfering with the detection conclusions. This improves the accuracy and effectiveness of cross-compiler inconsistency defect detection results between Solidity compilers, further enhancing the reference value of the detection report.

[0159] For comparison of technical effectiveness, existing technologies can be referenced. Fuzzing is an automated testing technique that generates a large number of test programs or input data to trigger potential defects in the system under test. It is widely used in complex systems such as operating systems, compilers, and virtual machines. Program generation technology, closely related to fuzzing, automatically constructs test programs that conform to language specifications through syntax rules, abstract syntax trees, or intermediate representations, providing high-quality samples for fuzzing. In recent years, program generation has gradually developed towards rule-driven, structure-aware, and semantically constrained approaches, improving defect triggering capabilities. In compiler testing, fuzzing is often combined with program generation or mutation techniques to automatically construct or modify the source program to discover defects during the compilation or execution phase. However, existing technologies mostly focus on a single compiler, making it difficult to systematically reveal potential inconsistencies of the same program across different compilers.

[0160] Furthermore, in existing technologies, methods for detecting compiler defects or inconsistencies mainly fall into two categories: program generation and differential analysis.

[0161] (1) Program Generation Techniques: Program generation techniques are used to automatically construct test programs that conform to language specifications for fuzz testing. Existing methods include mutation generation based on syntax rules or abstract syntax trees, and program generation using large language models. For example, FUZZOL and Superion can generate new test programs by modifying abstract syntax trees; FuzzGPT can generate uncommon program inputs to trigger boundary conditions; MetaMut uses LLM (Large Language Model) to automatically generate semantically aware mutants to perform diverse mutations on programs. Through these methods, test programs with diverse structures and complex semantics can be generated to discover potential defects in compilers.

[0162] (2) Differential Analysis Techniques: Differential analysis identifies potential inconsistencies by comparing the outputs of different compilers or executors on the same program. It detects compiler defects by comparing the outputs generated by the same compiler at different optimization levels; furthermore, it identifies problems by comparing the outputs of different compilers. Some research focuses on reducing false positives during inconsistency detection, for example, by defining program patterns that may lead to false positives and deliberately avoiding generating these programs during the program generation phase.

[0163] Based on the above, existing Solidity compiler testing methods and fuzzer tools are mainly used to detect errors within a single compiler, and have the following drawbacks in detecting cross-compiler inconsistencies:

[0164] (1) Limited program generation capabilities

[0165] Existing fuzzer mutation strategies are relatively coarse-grained. For example, POLYGLOT inserts, deletes, or replaces elements in the intermediate representation; FUZZOL modifies the abstract syntax tree nodes; and afl-compiler-fuzzer uses program disassembly and reassembly. These methods require numerous random attempts to generate effective test programs when faced with complex syntax structures, resulting in low efficiency and difficulty in covering boundary conditions or corner cases. Furthermore, existing tools lack design for boundary conditions. Even tools like LLM4CBI or DFUZZ, which employ specific mutation rules, primarily target domain-specific problems rather than compiler consistency, making it difficult to generate high-quality test programs that trigger cross-compiler inconsistencies.

[0166] (2) Insufficient ability to identify inconsistencies

[0167] Existing tools primarily rely on compiler error detection or optimization difference detection, such as DeSCDT and yul_proto_diff_ossfuzz for detecting Solc optimization issues. These methods cannot comprehensively identify differences in program execution results between different compilers, cannot determine whether compilers have semantic inconsistencies, and cannot solve cross-compiler correctness determination problems.

[0168] To address the shortcomings of the two aforementioned technologies, this invention provides a method for detecting inconsistencies between Solidity compilers. By automatically generating test programs that can trigger compiler differences, this method systematically detects unknown defects that may exist in different Solidity compilers during compilation and execution, thereby improving the security and reliability of the compilers.

[0169] Specifically, such as Figure 8 As shown, the inconsistency detection method between Solidity compilers proposed in this invention mainly comprises three stages: a mutation rule generation stage, a fine-grained mutation stage, and an execution-based detection stage. In the mutation rule generation stage, boundary conditions in the target Solidity compiler and executor are first identified. Then, the syntactic features that can trigger these boundary conditions are analyzed, and syntax-oriented mutation rules are automatically generated. Based on this, the syntax-oriented mutation rules are further filtered and refined to generate boundary-oriented mutation rules, so as to more accurately trigger sensitive regions in the compiler and executor.

[0170] In the fine-grained mutation phase, the seed program undergoes adaptive mutation. This phase employs a mutation-based fuzzy testing loop mechanism to continuously generate more potentially valuable test program variants from the given seed program. Simultaneously, a reinforcement learning mechanism is introduced to dynamically optimize subsequent mutation strategies based on feedback information from the newly generated programs during compilation and execution, thereby improving testing efficiency and reducing the probability of defect triggering.

[0171] In the execution-based detection phase, inconsistencies are identified using differential analysis. Newly generated test programs are compiled and executed on multiple Solidity build toolchains, with semantic alignment performed during this process, and the test outputs compared and analyzed. After eliminating false positives, programs that trigger compilation or execution inconsistencies are logged and reported. This invention employs a boundary condition-guided mutation strategy, aiming to utilize boundary conditions in the source code to guide program mutation. Simultaneously, an execution-based inconsistency determiner is implemented, capable of identifying not only compilation and runtime errors but also subtle differences in execution results. Furthermore, through empirical evaluation of its effectiveness compared to other state-of-the-art methods, 64 previously unknown inconsistencies were discovered in six popular Solidity compilers.

[0172] Compared to existing technologies, this invention can more efficiently generate test programs that trigger inconsistencies between different Solidity compilers. Existing fuzzing methods often employ coarse-grained, general mutation strategies, making it difficult to generate programs with complex syntax that can trigger compiler boundary conditions, resulting in low defect triggering efficiency. This invention extracts boundary conditions from the compiler and executor source code and combines them with program syntax features to generate boundary-oriented, fine-grained mutation rules. This enables the generated test programs to specifically cover compiler-sensitive paths, thereby significantly improving the inconsistency triggering capability.

[0173] Furthermore, this invention can more accurately detect compiler inconsistencies. Existing technologies typically only compare compilation results or are limited to the optimization behavior of a single compiler, making it difficult to detect logical inconsistencies across compilers and execution environments. This invention, by compiling and executing programs on multiple compilers and executors and performing semantic alignment and differential analysis on different output results, achieves effective identification of various types of compiler inconsistencies, thereby improving the comprehensiveness and reliability of defect detection.

[0174] In this embodiment of the invention, a method for detecting inconsistencies between Solidity compilers is provided. This method involves acquiring initial seed programs, complete source code, and official discrepancy documents for multiple Solidity compilers, as well as the complete source code of the executors corresponding to each Solidity compiler. Based on explicit and implicit boundary conditions and feature extraction prompts, a large model is used to generate explicit and implicit code block data corresponding to each Solidity compiler based on the complete source code of each Solidity compiler and the complete source code of each executor. Based on predefined guidance rules, feature selection prompts, and mutation rule selection prompts, the large model generates target mutation rules matching each initial seed program based on the explicit and implicit code block data, complete source code, initial seed programs, and the complete source code of each executor. Based on predefined program repair prompts, a benchmark compiler and the large model perform program repair on each initial seed program according to the multiple target mutation rules, outputting multiple initial test program variants. The large model is then fine-tuned based on each initial test program variant and the corresponding target mutation rules to obtain a micro-tuning result. The large model is adjusted, and multiple target test program variants are output through the fine-tuned large model. Inconsistency identification is performed by combining each Solidity compiler and each executor. The output shows the test program variants that trigger compilation inconsistencies and their corresponding inconsistencies in compilation state and error messages, as well as the test program variants that trigger execution inconsistencies and their corresponding inconsistencies in execution state and execution output. Based on the official difference documents of each Solidity compiler, the test program variants that trigger compilation inconsistencies and their corresponding inconsistencies in compilation state and error messages, and the test program variants that trigger execution inconsistencies and their corresponding inconsistencies in execution state and execution output, a Solidity compiler inconsistency detection report is generated. Based on the above scheme, this invention compiles and executes the initial seed program on multiple Solidity compilers and their corresponding executors, and performs semantic alignment and differential analysis on different output results, effectively identifying multiple types of compiler inconsistencies, thereby improving the comprehensiveness of cross-compiler inconsistency defect detection between Solidity compilers.

[0175] Please see Figure 9 , Figure 9 This is a structural block diagram of an inconsistency detection system between Solidity compilers provided in Embodiment 2 of the present invention.

[0176] This invention provides a system for detecting inconsistencies between Solidity compilers, comprising:

[0177] Module 901 is used to obtain the initial seed program, complete source code and official difference documents of multiple Solidity compilers, as well as the complete source code of the executor corresponding to each Solidity compiler.

[0178] The first generation module 902 is used to generate explicit and implicit code block data corresponding to each Solidity compiler based on explicit and implicit boundary conditions and feature extraction prompts, using a large model based on the complete source code of each Solidity compiler and the complete source code of each executor.

[0179] The second generation module 903 is used to select prompts based on predefined guiding rules, feature selection prompts and mutation rules. It adopts a large model to generate target mutation rules that match each initial seed program based on the explicit and implicit code block data, complete source code, initial seed program and complete source code of each executor corresponding to each Solidity compiler.

[0180] Output module 904 is used to repair each initial seed program based on predefined program repair prompts, using a benchmark compiler and large model according to multiple target mutation rules, and output multiple initial test program variants.

[0181] The identification module 905 is used to fine-tune the large model according to each initial test program variant and the corresponding target mutation rule to obtain the fine-tuned large model. It outputs multiple target test program variants through the fine-tuned large model, and performs inconsistency identification in combination with each Solidity compiler and each executor. It outputs test program variants that trigger compilation inconsistency and their corresponding compilation status inconsistency results and error information inconsistency results, as well as test program variants that trigger execution inconsistency and their corresponding execution status inconsistency results and execution output inconsistency results.

[0182] The false positive elimination module 906 is used to generate an inconsistency detection report between Solidity compilers based on the official difference documents of each Solidity compiler, the test program variants that trigger compilation inconsistencies and the corresponding inconsistent compilation status results and error information results, and the test program variants that trigger execution inconsistencies and the corresponding inconsistent execution status results and execution output results.

[0183] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system and modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0184] This invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program; when the computer program is executed by the processor, the processor performs the steps of the inconsistency detection method between Solidity compilers as described in the above embodiments.

[0185] This invention also provides a computer-readable storage medium storing a computer program / instructions thereon, which, when executed by a processor, implements the steps of the inconsistency detection method between Solidity compilers as described in the above embodiments.

[0186] This invention also provides a computer program product, including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, wherein when the program instructions are executed by a computer, the computer performs the steps of the inconsistency detection method between Solidity compilers as described in the above embodiments.

[0187] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0188] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0189] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0190] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0191] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for detecting inconsistencies between Solidity compilers, characterized in that, include: Obtain the initial seed program, complete source code, and official difference documentation for multiple Solidity compilers, as well as the complete source code of the executor corresponding to each Solidity compiler. Based on explicit and implicit boundary conditions and feature extraction prompts, a large model is used to generate explicit and implicit code block data corresponding to each Solidity compiler according to the complete source code of each Solidity compiler and the complete source code of each executor. Based on predefined guiding rules, feature selection prompts, and mutation rule selection prompts, the large model generates target mutation rules that match each initial seed program according to the explicit and implicit code block data, complete source code, initial seed program, and complete source code of each executor corresponding to each Solidity compiler. Based on predefined program repair prompts, a benchmark compiler and the large model are used to repair each of the initial seed programs according to multiple target mutation rules, and output multiple initial test program variants. The large model is fine-tuned according to each initial test program variant and the corresponding target mutation rule to obtain a fine-tuned large model. Multiple target test program variants are output through the fine-tuned large model. Inconsistency identification is performed by combining each Solidity compiler and each executor. The output results are as follows: test program variants that trigger compilation inconsistency and corresponding compilation state inconsistency results and error message inconsistency results; test program variants that trigger execution inconsistency and corresponding execution state inconsistency results and execution output inconsistency results. Based on the official difference documents of each Solidity compiler, the test program variants that trigger compilation inconsistencies and their corresponding inconsistent compilation status results and error messages, and the test program variants that trigger execution inconsistencies and their corresponding inconsistent execution status results and execution output results, an inconsistency detection report between Solidity compilers is generated.

2. The method for detecting inconsistencies between Solidity compilers according to claim 1, characterized in that, The explicit and implicit boundary conditions include explicit boundary conditions and implicit boundary conditions; the explicit and implicit code block data includes explicit code blocks, implicit code blocks, explicit code block language features, and implicit code block language features; based on the explicit and implicit boundary conditions and feature extraction prompts, a large model is used to generate explicit and implicit code block data corresponding to each Solidity compiler according to the complete source code of each Solidity compiler and the complete source code of each executor, including: Explicit boundary conditions are used to identify fixed identifiers in the complete source code of each Solidity compiler and its corresponding executor, and the explicit code block corresponding to each Solidity compiler is output. Based on implicit boundary conditions, the complete source code of each Solidity compiler and its corresponding executor is input into the large model for implicit anomaly identification, and the implicit code block corresponding to each Solidity compiler is output. Based on the feature extraction prompts, the explicit and implicit code blocks corresponding to each Solidity compiler are input into the large model for feature analysis, and the explicit and implicit code block language features corresponding to each Solidity compiler are output.

3. The method for detecting inconsistencies between Solidity compilers according to claim 2, characterized in that, The predefined guidance rules include syntax guidance rules and boundary guidance rules; the selection of guidance rules based on the predefined guidance rules, feature selection prompts, and mutation rule selection prompts, using the large model to generate target mutation rules matching each initial seed program based on the explicit and implicit code block data, complete source code, initial seed program, and complete source code of each executor corresponding to each Solidity compiler, including: Syntax-oriented prompt words are generated based on syntax-oriented rules, and the explicit and implicit code block language features corresponding to each Solidity compiler are input into the large model to output syntax-oriented mutation rules. Boundary-oriented prompts are generated based on boundary-oriented rules. The target source code fragments from the complete source code of each Solidity compiler and its corresponding executor, the explicit code blocks, implicit code blocks, explicit code block language features, and implicit code block language features corresponding to each Solidity compiler, as well as the syntax-oriented mutation rules, are input into the large model, and boundary-oriented mutation rules are output. Based on the feature selection prompts, the explicit code block language features and implicit code block language features corresponding to each initial seed program and each Solidity compiler are input into the large model, and the target language features matching each initial seed program are output. Based on the mutation rules, select prompt words, input each initial seed program, the syntax-guided mutation rule, and the boundary-guided mutation rule into the large model, and output the target mutation rule that matches each initial seed program.

4. The method for detecting inconsistencies between Solidity compilers according to claim 1, characterized in that, The predefined program repair prompts, using a benchmark compiler and the large model, perform program repair on each of the initial seed programs according to multiple target mutation rules, outputting multiple initial test program variants, including: Based on the target mutation rules, the corresponding initial seed program is mutated to output multiple mutated Solidity programs. Each of the modified Solidity programs is input into the benchmark compiler for compilation and verification, and the error messages corresponding to each of the modified Solidity programs are obtained. Based on the predefined program repair prompts, each of the mutated Solidity programs and the corresponding error messages are input into the large model, and multiple initial test program variants are output.

5. The method for detecting inconsistencies between Solidity compilers according to claim 1, characterized in that, The large model is fine-tuned according to each initial test program variant and its corresponding target mutation rule to obtain a fine-tuned large model. Multiple target test program variants are output through the fine-tuned large model. Inconsistency identification is performed using each Solidity compiler and each executor, outputting test program variants that trigger compilation inconsistencies and their corresponding compilation state inconsistencies and error message inconsistencies, as well as test program variants that trigger execution inconsistencies and their corresponding execution state inconsistencies and execution output inconsistencies. Calculate the reward score for each of the initial test program variants based on the inconsistency detection results. A fine-tuning dataset is constructed using the various initial test program variants and their corresponding reward scores and target mutation rules as samples. The large model is fine-tuned based on the fine-tuning dataset, and the fine-tuned large model is output. The finely tuned large model is used to generate target test program variants corresponding to each initial seed program according to each initial seed program and the corresponding target mutation rules; Each of the target test program variants is input into the corresponding Solidity compiler for compilation, resulting in multiple compilation output results corresponding to each of the target test program variants. Compare the compilation output results corresponding to each of the target test program variants, identify and output the test program variants that trigger compilation inconsistencies and the corresponding inconsistent compilation status results and inconsistent error messages; Extract the bytecode generated by each of the target test program variants in each of the Solidity compilers, and input the multiple bytecodes corresponding to each of the target test program variants into the corresponding executors for execution, thereby obtaining the multiple executor output results corresponding to each of the target test program variants; The output results of multiple executors corresponding to each of the target test program variants are processed for format adaptation to obtain multiple adapted executor output results corresponding to each of the target test program variants; By comparing the output results of multiple adapted executors corresponding to each of the target test program variants, the test program variants that trigger execution inconsistencies and the corresponding execution state inconsistencies and execution output inconsistencies are identified and output.

6. The method for detecting inconsistencies between Solidity compilers according to claim 1, characterized in that, The process generates an inconsistency detection report between Solidity compilers based on the official difference documents of each Solidity compiler, the test program variants that trigger compilation inconsistencies and their corresponding compilation status inconsistencies and error message inconsistencies, and the test program variants that trigger execution inconsistencies and their corresponding execution status inconsistencies and execution output inconsistencies. This report includes: False positive elimination rules are constructed based on Solidity code snippets from the official diff documentation for each Solidity compiler. The test program variants that trigger compilation inconsistencies and execution inconsistencies are matched with the false positive elimination rules, and test program variants that do not match are retained as having inconsistencies. Based on the inconsistencies in the test program variants and the corresponding inconsistent execution state and output results, as well as the inconsistent compilation state and error messages, a final Solidity compiler inconsistency detection report is generated.

7. A system for detecting inconsistencies between Solidity compilers, characterized in that, include: The acquisition module is used to acquire the initial seed program, complete source code, and official difference documentation for multiple Solidity compilers, as well as the complete source code of the executor corresponding to each Solidity compiler. The first generation module is used to generate explicit and implicit code block data corresponding to each Solidity compiler based on explicit and implicit boundary conditions and feature extraction prompts, using a large model according to the complete source code of each Solidity compiler and the complete source code of each executor. The second generation module is used to generate target mutation rules that match each initial seed program based on predefined guiding rules, feature selection prompts, and mutation rule selection prompts, using the large model according to the explicit and implicit code block data, complete source code, initial seed program, and complete source code of each executor corresponding to each Solidity compiler. The output module is used to repair each of the initial seed programs based on predefined program repair prompts, using a benchmark compiler and the large model according to multiple target mutation rules, and output multiple initial test program variants. The identification module is used to fine-tune the large model according to each initial test program variant and the corresponding target mutation rule to obtain the fine-tuned large model, and output multiple target test program variants through the fine-tuned large model. It also performs inconsistency identification by combining each Solidity compiler and each executor, and outputs test program variants that trigger compilation inconsistencies and their corresponding compilation status inconsistencies and error information inconsistencies, as well as test program variants that trigger execution inconsistencies and their corresponding execution status inconsistencies and execution output inconsistencies. The false positive elimination module is used to generate an inconsistency detection report between Solidity compilers based on the official difference documents of each Solidity compiler, the test program variant that triggers the compilation inconsistency and the corresponding compilation status inconsistency results and error information inconsistency results, and the test program variant that triggers the execution inconsistency and the corresponding execution status inconsistency results and execution output inconsistency results.

8. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the inconsistency detection method between Solidity compilers as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed, it implements the inconsistency detection method between Solidity compilers as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, wherein when the program instructions are executed by a computer, the computer performs the steps of the inconsistency detection method between Solidity compilers as described in any one of claims 1-6.

Images