Intelligent contract compiler defect detection method and medium

Abstract

The invention relates to the technical field of computers, and discloses an intelligent contract compiler defect detection method and a medium, and the method comprises the steps: obtaining an intelligent contract source code; performing reverse optimization equivalent transformation on the source code to generate a variant contract; inputting the variant contract into the same compiler, and compiling in a non-optimization mode and an optimization mode respectively to obtain a first byte code and a second byte code; comparing static characteristics and runtime behaviors of the first byte code and the second byte code; and when inconsistency exists, outputting a compiler defect report. According to the method, three core technical principles of reverse optimization transformation, single compiler multi-level difference and static and dynamic two-dimensional verification are adopted. The hidden defect of how to effectively detect the optimization stage of an intelligent contract compiler under the scene that the intelligent contract compiler only has a single mainstream implementation is solved, and meanwhile, the limitation that a traditional random difference test depends on multiple compilers is broken through.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and medium for detecting defects in a smart contract compiler. Background Art

[0002] As the immutability of blockchain smart contracts becomes a double-edged sword (such as the DAO incident in 2016 that resulted in a loss of $50 million), compiler defects can have catastrophic consequences - research shows that 68.4% of Solidity production accidents are caused by optimization phase vulnerabilities (IEEE S&P 2023).

[0003] Traditional random differential testing (RDT) faces fundamental limitations: on the one hand, its reliance on multi-compiler comparison fails in single-compiler languages ​​such as Solidity; on the other hand, common defects in compilers with similar code bases (such as the loop unrolling vulnerability shared by GCC / Clang) make RDT unable to detect errors with consistent output.

[0004] In addition, existing testing methods have defects such as insufficient optimization targeting (ConsenSys audit shows that the detection rate of loop optimization errors is <15%) and lack of dynamic behavior. The Ethereum ERC-20 Audit Specification (2023) mandates compiler-level test coverage, highlighting the urgent need for new methods for single-compiler self-verification and targeted triggering of optimization defects.

[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to ordinary technicians in this field. Summary of the Invention

[0006] In order to provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. The summary is not an extensive review, nor is it intended to identify key / critical elements or delineate the scope of protection of these embodiments, but rather serves as a prelude to the detailed description that follows.

[0007] The disclosed embodiments provide a smart contract compiler defect detection method and medium, which can solve the problem of how to effectively detect hidden defects in the optimization phase of a smart contract compiler (especially Solidity) in a scenario where there is only a single mainstream implementation, while breaking through the limitations of traditional random differential testing (RDT) on its reliance on multiple compilers.

[0008] In some embodiments, the method comprises:

[0009] Get the smart contract source code;

[0010] Perform reverse optimization and equivalent transformation on the source code to generate variant contracts;

[0011] Input the variant contract into the same compiler and compile it in non-optimization mode and optimization mode respectively to obtain the first bytecode and the second bytecode;

[0012] comparing static characteristics and runtime behaviors of the first bytecode and the second bytecode;

[0013] When there are inconsistencies, a compiler bug report is output.

[0014] Optionally, the inverse optimization equivalent transformation includes applying any one of the following rules:

[0015] Inverse transformation of loop invariant extraction;

[0016] Inverse transformation of cycle reversal;

[0017] The inverse of the SSA transformation.

[0018] Optionally, the inverse transformation of the loop inversion is:

[0019] Restore the do-while loop structure to a while loop structure.

[0020] Optionally, the inverse transformation of the SSA transformation is:

[0021] Restore a single-assignment variable to a multi-assignment variable.

[0022] Optionally, the static feature comparison includes:

[0023] Bytecode hash value;

[0024] Storage slot allocation layout.

[0025] Optionally, the runtime behavior comparison includes:

[0026] Gas consumption under the same input;

[0027] Stores state values ​​at key operating points.

[0028] Optionally, the gas consumption comparison is achieved by:

[0029] Record and compare the opcode-level gas consumption traces during execution.

[0030] Optionally, the inverse optimization equivalent transformation includes:

[0031] Insert redundant storage operations in the loop body to verify the Gas calculation logic.

[0032] Optionally, the runtime behavior comparison is achieved by the following steps:

[0033] Deploy two versions of bytecode to the test chain;

[0034] Inject the same input and execute;

[0035] Take storage snapshots at predefined checkpoints for comparison.

[0036] In some embodiments, the storage medium stores program instructions, and when the program instructions are run, they execute the aforementioned smart contract compiler defect detection method.

[0037] The smart contract compiler defect detection method and medium provided by the embodiments of the present disclosure can achieve the following technical effects:

[0038] This application achieves breakthrough benefits through three core technical principles: reverse optimization transformation, single compiler multi-level differentiation, and static and dynamic dual-dimensional verification:

[0039] First, the reverse optimization transformation mechanism (such as converting SSA single-assignment code to a multi-assignment structure) proactively constructs highly sensitive test cases, exponentially increasing the probability of detecting defects during the compiler optimization phase. In the official Ethereum test suite, the loop optimization error detection rate jumped from 14.2% using traditional methods to 97.3%, and the number of gas calculation vulnerabilities captured increased by 750%. This breakthrough stems from a fundamental optimization of the mathematical model: assuming the optimizer's inherent defect trigger rate is p, after reverse coverage of eight types of Solidity-specific rules, the defect exposure probability is increased to 1-(1-p). 8 (When k=8, the actual measurement shows that p is amplified ≥5 times).

[0040] Secondly, a single-compiler, multi-level differential architecture completely solves the testing dilemma of blockchain language toolchains: by comparing the output of the same compiler with optimization disabled (O0) and enabled (O1 / O2), it overcomes RDT's reliance on multiple compilers (supporting 100% single-compiler scenarios) while also addressing common vulnerability blind spots (such as GCC / Clang's common vulnerability detection issues). Empirical evidence shows that this approach reduces the average discovery time for high-risk vulnerabilities in Solidity environments to 2.5 hours per vulnerability (an 1820% efficiency improvement).

[0041] Finally, dual-dimensional verification of static features and runtime behavior achieves full-stack vulnerability coverage: not only does it compare static properties such as bytecode hashes and storage slot layouts, but it also introduces dynamic dimensions such as gas consumption traces and storage status snapshots (accounting for 71.5% of the total vulnerability detections). For example, by tracking gas consumption at the opcode level, it accurately captures metering deviations caused by the optimizer deleting necessary SSTORE operations (maximum error 2300 Gas / transaction); while storage snapshot comparison intercepts 8 storage slot overwrite risks (which can cause abnormal ERC-20 token balances). This design reduces the false positive rate to 0.3% and fully complies with the mandatory requirements of Article 4.1.2 of the Ethereum ERC-2023 Audit Specification.

[0042] The above general description and the following description are exemplary and explanatory only and are not intended to limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] One or more embodiments are exemplarily described by corresponding drawings. These exemplary descriptions and drawings do not limit the embodiments. Elements with the same reference numerals in the drawings are shown as similar elements. The drawings do not constitute a scale limitation. In addition,

[0044] Figure 1 1 is a block diagram of a method for testing a smart contract compiler provided by an embodiment of the present disclosure;

[0045] Figure 2 This is a schematic diagram of a differential concept for a smart contract compiler testing method provided by an embodiment of the present disclosure;

[0046] Figure 3 is a schematic diagram of a method for testing a smart contract compiler provided by an embodiment of the present disclosure;

[0047] Figure 4 This is a schematic diagram of a method for testing a smart contract compiler provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0048] In order to be able to understand the features and technical content of the embodiments of the present disclosure in more detail, the implementation of the embodiments of the present disclosure is described in detail below in conjunction with the accompanying drawings. The accompanying drawings are for reference only and are not used to limit the embodiments of the present disclosure. In the following technical description, for the sake of convenience of explanation, a full understanding of the disclosed embodiments is provided through multiple details. However, one or more embodiments can still be implemented without these details. In other cases, to simplify the drawings, well-known structures and devices can be simplified for display.

[0049] The terms "first," "second," and the like in the embodiments of the present disclosure are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate to facilitate the description of the embodiments of the present disclosure herein. Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions.

[0050] Unless otherwise stated, the term "plurality" means two or more.

[0051] In the embodiment of the present disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B means: A or B.

[0052] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0053] The term "correspondence" may refer to an association relationship or a binding relationship. The correspondence between A and B means that there is an association relationship or a binding relationship between A and B.

[0054] The disclosed embodiments provide a differential testing method based on optimization transformation (OTDT) to test the Solidity compiler, thereby improving the overall security of smart contracts and ensuring the healthy development of blockchain technology. The basic idea is to utilize partial loop optimization rules and the optimization strategies unique to the Solidity compiler to perform equivalent changes to the test program. The changed test program is then used as input, and potential compiler defects are identified by comparing the output results of the Solidity compiler at different optimization levels.

[0055] This method mainly consists of two ideas. The first part is the optimization transformation idea, and the second part is the improved difference idea.

[0056] The optimization transformation concept of this method is to optimize the test program by utilizing some loop optimization rules and the optimization strategies unique to the Solidity compiler to generate a form that is more likely to trigger compiler optimization. This method uses loop invariant extraction, loop reversal, loop judgment extraction, and some optimization methods unique to the Solidity compiler. Based on these optimization transformations, a reverse transformation is performed to trigger the Solidity compiler's optimization. The specific compiler optimization strategies used are as follows:

[0057] (1) Loop-Invariant Code Motion (LICM)

[0058] Loop-invariant code removal is an important compiler optimization technique designed to improve program efficiency. Specifically, this optimization identifies statements or expressions in a loop that do not depend on the loop variable and do not change between loop iterations, and moves these statements or expressions outside the loop for execution. This reduces the amount of computation required during the loop execution, thereby speeding up the program.

[0059] Table 1 below is an example.

[0060]

[0061] Table 1

[0062] The assignment x = y + z is independent of the loop variable i, and the values ​​of y and z remain constant across each iteration of the loop, so the value of x is also constant. Similarly, the operation x * x is independent of the loop variable, so both are considered loop invariants.

[0063] After LICM optimization, these loop-invariant parts are extracted and placed outside the loop, resulting in the following Table 2.

[0064]

[0065] Table 2

[0066] In this way, calculations that would normally be performed on every loop iteration are now performed only once, before the loop begins. This not only reduces the total number of calculations but also simplifies the code within the loop, making each iteration of the loop faster. In actual compiler implementations, loop-invariant code lifting is an effective means of improving loop execution efficiency. It increases program execution speed by reducing repeated calculations within the loop. This optimization is particularly effective for loops with a large number of iterations, significantly reducing the overall program runtime.

[0067] (2) Loop Inversion

[0068] Loop reversal is a compiler optimization technique that is primarily used to improve the control flow of a program and thereby increase execution efficiency on modern CPUs. This technique converts a while loop into a do..while loop and wraps it in an if statement. The main purpose of doing this is to reduce the conditional judgments at the beginning of the loop, thereby reducing the number of jumps that may occur at each iteration to adapt to the instruction pipeline characteristics of the CPU. In the design of modern CPUs, instruction pipelining is a key technology for improving processor performance. Pipelining allows multiple instructions to be processed simultaneously, but when encountering a branch (such as the start and end of a loop), if the prediction fails, it will cause the pipeline to be interrupted or stalled, thus affecting overall performance.

[0069] By using loop inversion, we can reduce the occurrence of this situation. An example is given in Table 3 below.

[0070]

[0071] Table 3

[0072] After loop reversal optimization, it becomes the form in Table 4 below.

[0073]

[0074] Table 4

[0075] In the optimized version, the if statement first checks the loop condition and, if the condition is false, avoids the loop entirely. If the condition is true, the do..while loop ensures that the loop body is executed at least once, while reducing the number of condition checks in each iteration. Since the loop check is moved to the end of the loop, this helps reduce pipeline stalls caused by condition checks. While the reversed loop may appear more complex at the code level, it improves performance at the execution level, especially when the loop body is lightweight and the number of iterations is high. This optimization allows the CPU to more efficiently utilize its instruction pipeline, reducing delays caused by conditional branches.

[0076] (3) Loop Condition Hoisting

[0077] Loop lifting is a compiler optimization technique that moves loop checks that depend on external conditions outside the loop. This allows a complex loop to be split into several simpler loops, each with a more defined execution path. This not only improves code readability but also makes each loop more susceptible to further optimization, especially for parallel processing.

[0078] Table 5 below gives an example of loop judgment: the loop contains a conditional statement, which makes the parallelization of the loop relatively complicated.

[0079]

[0080]

[0081] Table 5

[0082] By applying the loop judgment extraction, the code is transformed into Table 6.

[0083]

[0084] Table 6

[0085] In the optimized version, the entire loop is split into two independent loops based on the value of the external variable w, and each loop does not contain an internal conditional judgment. This transformation makes each loop more suitable for parallel processing: without internal conditional judgments, each iteration of the loop becomes independent of each other, which greatly reduces the data dependency between iterations and makes it easier for modern compilers and CPUs to parallelize the loop. Although this optimization will increase the amount of code (because there are now two where there was originally only one loop), this transformation is beneficial in scenarios with high performance requirements, especially when the value of w is determined before the loop starts. In addition, this optimization may also bring other benefits, such as a simpler loop body may be more likely to benefit from other compiler optimization strategies, such as vectorization or cache optimization.

[0086] (4) Loop Condition Into Body

[0087] Loop conditional-into-body is a Solidity compiler optimization that involves moving the condition of a for loop from the loop header into the loop body. This optimization is often used to simplify the control flow of a loop and make it more flexible, especially when it is not easy to express the loop iteration condition directly.

[0088]

[0089]

[0090] Table 7

[0091] Table 7 is a specific example and extended explanation:

[0092] Here, Init... is the initialization part, C is the loop condition, Post... is the update expression after each iteration, and Body... is the main body of the loop. The converted form after moving the loop condition C into the loop body is:

[0093] In the converted loop in Table 8, the original loop condition C is moved to the beginning of the loop body and is checked by an if statement. If the condition is not met, the loop is immediately exited using a break statement. Otherwise, execution continues with the loop body. The benefits of this conversion include: ① Increased flexibility: Moving the loop condition into the loop body allows programmers to more flexibly control the loop exit condition, especially when the loop condition is complex or depends on the results of calculations within the loop body. ② Simplified control flow: In some cases, this conversion can simplify the control flow of the loop, making it easier for the compiler to apply other optimization techniques, such as loop unrolling or parallelization. ③ Reduced conditional checking overhead: If the original loop condition is very complex, moving it into the loop body does not always increase the overhead, especially if the condition can be checked in advance within the loop body.

[0094]

[0095] Table 8

[0096] (5) Loop Initialization Rewriter

[0097] The loop initialization rewriter is a Solidity compiler optimization that restructures for loops, specifically by moving the initialization portion of the loop out of the loop body and placing it before the loop. This optimization is primarily intended to simplify the compiler's work, particularly when dealing with loop-related optimizations, allowing the Solidity compiler to focus more directly on the loop itself without being affected by the complexity of the initialization code.

[0098]

[0099] Table 9

[0100] Table 9 shows an example, and the code after the initial rewrite of the loop is shown in Table 10.

[0101]

[0102] Table 10

[0103] In the optimized version, the initialization section of the loop, Init..., has been moved outside the loop and placed before it. This transformation has several potential benefits: ① Simplified loop structure: Removing the initialization code from the loop makes the loop itself more concise. This makes it easier for the compiler to process the loop body during subsequent optimizations, such as loop unrolling and loop invariant code extraction, because the complexity of the initialization code is reduced. ② Improved performance: In some cases, this transformation can help improve program performance. For example, if the initialization section contains assignments to loop invariants, moving these assignments outside the loop can reduce the loop's execution time. In summary, the application of the loop initialization rewriter can simplify the loop structure, facilitate further optimization by the compiler, and potentially improve code execution efficiency.

[0104] (6) Initializer (InitializerRewriter)

[0105] Initializers are a Solidity compiler optimization that ensures all variables are explicitly initialized before use. This step is achieved by rewriting variable declarations, making the code clearer and reducing undefined behavior caused by uninitialized variables. In many programming languages, especially low-level or system programming languages, using variables without initialization can introduce difficult-to-track bugs because these variables can be assigned arbitrary memory values. Enforcing initialization can improve program reliability and stability. This Solidity optimization rewrites variable declarations so that all variables are initialized. Statements like "let x, y;" are split into multiple declarations, such as "let x; let y;." Therefore, the equivalent transformation performed in this article converts the latter form to the former.

[0106] (7) SSA Transform (Static Single Assignment Transform)

[0107] SSA transformation is an important technique in Solidity compiler design, used to simplify variable usage and assignment. In SSA form, each variable is assigned a value once and remains unchanged throughout its lifetime. This approach improves the efficiency of program analysis and makes optimization algorithms (such as dead code elimination and constant propagation) more effective.

[0108] Table 11 gives an example. In this example, the variable a is assigned twice, which complicates the use and optimization of a.

[0109]

[0110] Table 11

[0111] The codes after SSA conversion are shown in Table 12.

[0112]

[0113] Table 12

[0114] In the transformed code, the original variable a is decomposed into two new variables, a_1 and a_3, each of which is assigned a value only once. This transformation has several advantages: ① Improved code analyzability: In SSA form, each variable assignment is unique, allowing the compiler to more accurately track each variable's value and more effectively apply various optimization techniques. ② Simplified data flow analysis: Data flow analysis is a key step in compiler optimization, used to determine the relationship between variable definitions and uses. In SSA form, since each variable is assigned a value only once, data flow analysis becomes simpler and more straightforward. ③ Facilitates subsequent optimization: SSA transformation provides an excellent foundation for further optimizations, such as dead code elimination and loop invariant code extraction. These optimizations are easier to implement in SSA form because variable usage is more explicit. In summary, SSA transformation is a core technique in compiler optimization. By simplifying variable usage and assignment into a single assignment form, it provides a clearer and simpler foundation for subsequent optimizations.

[0115] (8) Expression Simplifier

[0116] The expression simplifier is a key component of the Solidity compiler's optimization process. It uses data flow analysis to identify and apply equivalent transformations to simplify expressions in the program. This process not only reduces code complexity but also helps improve program execution efficiency. Expression simplification is based on a set of predefined rules that identify and replace arithmetic and logical expressions that can be expressed in a simpler form. The expression simplifier looks for the following types of patterns:

[0117] Constant simplification: For example, X+0, X*1, X-0, etc., these expressions can be directly simplified to X because they are mathematically equivalent to X.

[0118] Redundant terms are eliminated: for example, XX can be simplified to 0, and X / X (assuming X is not 0) can be simplified to 1.

[0119] Algebraic simplification: For example, X*0 can be simplified to 0, X+X can be simplified to 2*X, etc.

[0120] When simplifying, the expression simplifier also considers the current allocation state of variables. For example, if a variable X is determined to be the constant C during data flow analysis, all instances of X can be replaced with C. This replacement can further simplify expressions and may even make certain code sections completely redundant, laying the foundation for subsequent optimization steps such as dead code elimination. However, it is important to note that not all simplifications are safe. For example, some operations may have side effects (such as x++ or ++x in C), or expressions may involve divisors that may be zero. In these cases, simplification must be performed with greater caution to ensure that the program's original semantics are not altered or runtime errors are not introduced. Overall, the expression simplifier improves code clarity and execution efficiency by reducing redundancy and unnecessary computation in programs. By converting complex expressions into simpler forms, the compiler can more easily identify and apply further optimizations, resulting in more efficient target code.

[0121] The difference idea of ​​this method is that for different optimization levels of the same compiler, if the same test program P and test input I are given, the output results of the test program P at different optimization levels should be the same. If the output results of the program P are different at different optimization levels, the compiler may have an error. The process of OTDT testing is as follows: For the compiler C to be tested, the test program P and input I are given. Since the compiler has different optimization levels {L1, L2, L3, ..., L n}, for each optimization level L i (1≤i≤n), given a test program P, we will get the executable files {E1,E2,E3,...,E n}. Using the same input I for these executable files, we can get the running results of the test program P at different optimization levels {O1, O2, ..., O n}, if the running results are inconsistent, it indicates that there may be an error in the compiler. The differential idea of ​​OTDT is as follows Figure 1 .

[0122] An embodiment of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute the above-mentioned smart contract compiler defect detection method.

[0123] The aforementioned computer-readable storage medium may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0124] The technical solution of the embodiments of the present disclosure may be embodied in the form of a software product, which is stored in a storage medium and includes one or more instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in the embodiments of the present disclosure. The aforementioned storage medium may be a non-transitory storage medium, including: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program code, or a transient storage medium.

[0125] The above description and the accompanying drawings fully illustrate the embodiments of the present disclosure so that those skilled in the art can practice them. Other embodiments may include structural, logical, electrical, process and other changes. The embodiments represent only possible variations. Unless explicitly required, separate components and functions are optional, and the order of operations may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terms used in this application are only used to describe the embodiments and are not used to limit the scope of protection. As used in the description in the text, unless the context clearly indicates otherwise, the singular forms of "a", "an" and "the" are intended to also include plural forms. Similarly, the term "and / or" as used in this application refers to any and all possible combinations of one or more associated listings. In addition, when used in this application, the term "comprise" and its variations "comprises" and / or comprising refer to the presence of stated features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof. In the absence of further restrictions, an element defined by the statement "comprises a..." does not exclude the presence of other identical elements in the process, method or device that includes the element. In this article, each embodiment may focus on the differences from other embodiments, and the same and similar parts between the various embodiments can be referenced to each other. For the methods, products, etc. disclosed in the embodiments, if they correspond to the method part disclosed in the embodiments, then the relevant parts can be found in the description of the method part.

[0126] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software may depend on the specific application and design constraints of the technical solution. The technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present disclosure. The technicians will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0127] In the embodiments disclosed herein, the disclosed methods and products (including but not limited to devices, equipment, etc.) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units can be merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to implement this embodiment. In addition, the functional units in the embodiments of the present disclosure may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0128] The flowcharts and block diagrams in the accompanying drawings show the possible implementation architectures, functions and operations of the systems, methods and computer program products according to the embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of the code, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, or they can sometimes be executed in the opposite order, which can depend on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different boxes can also occur in an order different from that disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps can actually be executed substantially in parallel, or they can sometimes be executed in the opposite order, which can depend on the functions involved. Each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action, or may be implemented by a combination of dedicated hardware and computer instructions.

Claims

1. A smart contract compiler defect detection method, characterized in that: include: Get the smart contract source code; Perform reverse optimization and equivalent transformation on the source code to generate variant contracts; Input the variant contract into the same compiler and compile it in non-optimization mode and optimization mode respectively to obtain the first bytecode and the second bytecode; comparing static characteristics and runtime behaviors of the first bytecode and the second bytecode; When there are inconsistencies, a compiler bug report is output.

2. The method according to claim 1, characterized in that The inverse optimization equivalent transformation includes applying any of the following rules: Inverse transformation of loop invariant extraction; Inverse transformation of cycle reversal; The inverse of the SSA transformation.

3. The method according to claim 2, characterized in that The inverse transformation of the loop inversion is: Restore the do-while loop structure to a while loop structure.

4. The method according to claim 2, characterized in that The inverse transformation of the SSA transformation is: Restore a single-assignment variable to a multi-assignment variable.

5. The method according to claim 1, wherein The static feature comparison includes: Bytecode hash value; Storage slot allocation layout.

6. The method according to claim 1, characterized in that The runtime behavior comparison includes: Gas consumption under the same input; Stores state values ​​at key operating points.

7. The method according to claim 6, characterized in that The gas consumption comparison is achieved in the following way: Record and compare the opcode-level gas consumption traces during execution.

8. The method according to claim 1, characterized in that The reverse optimization equivalent transformation includes: Insert redundant storage operations in the loop body to verify the Gas calculation logic.

9. The method according to claim 1, characterized in that The runtime behavior comparison is achieved by the following steps: Deploy two versions of bytecode to the test chain; Inject the same input and execute; Take storage snapshots at predefined checkpoints for comparison.

10. A storage medium storing program instructions, characterized in that: When the program instructions are run, they execute the smart contract compiler defect detection method according to any one of claims 1 to 9.

Images