Translation verification method and device of EVM byte code compiler and computer equipment

Abstract

The invention relates to a translation verification method and device for an EVM bytecode compiler and computer equipment, and the method comprises the steps: obtaining an EVM bytecode sequence and a target machine code sequence obtained through compiling based on the EVM bytecode sequence; respectively performing symbolic execution on the EVM bytecode sequence and the target machine code sequence to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence; performing semantic matching on the first execution path and the second execution path to determine the first execution path and the second execution path which are matched with each other; and performing semantic equivalence verification on the matched first execution path and second execution path to obtain a verification result. According to the method and the device, the problem that whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent or not cannot be efficiently verified is solved, and whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent or not is efficiently verified.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to translation and verification methods, apparatuses, and computer equipment for the EVM bytecode compiler. Background Technology

[0002] To improve the execution efficiency of smart contracts, a common approach is to compile the Ethereum Virtual Machine (EVM) bytecode sequence into a native machine code sequence for a specific target architecture (such as x86-64 machine code, arm64 machine code, etc.). However, this compilation process may introduce biases, leading to inconsistencies between the compiled machine code sequence and the original EVM bytecode sequence in execution behavior. Therefore, it is necessary to verify the correctness of the compilation results.

[0003] Existing verification methods construct limited test inputs, execute the original EVM bytecode sequence and the compiled machine code sequence respectively, and compare the output results to determine consistency. However, this method is difficult to cover all branch scenarios and cannot efficiently verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0004] There is currently no effective solution to the problem that related technologies cannot efficiently verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent. Summary of the Invention

[0005] This embodiment provides a translation verification method, apparatus, and computer device for an EVM bytecode compiler to solve the problem in related technologies that it is impossible to efficiently verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0006] Firstly, this embodiment provides a translation verification method for an EVM bytecode compiler, including:

[0007] Obtain the EVM bytecode sequence and the target machine code sequence compiled based on the EVM bytecode sequence;

[0008] Symbolic execution is performed on the EVM bytecode sequence and the target machine code sequence respectively to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence;

[0009] The first execution path and the second execution path are semantically matched to determine the matching first execution path and the second execution path;

[0010] The semantic equivalence of the matching first execution path and second execution path is verified to obtain the verification results.

[0011] In some embodiments, the step of semantically matching the first execution path with the second execution path to determine matching first execution paths and second execution paths includes:

[0012] Determine the equivalent semantic anchor point between the first execution path and the second execution path; the equivalent semantic anchor point is the semantically equivalent operation instruction in the first execution path and the second execution path.

[0013] Based on the equivalent semantic anchor, the first execution path and the second execution path are matched to determine the matching first execution path and the second execution path.

[0014] In some embodiments, determining the equivalent semantic anchor point between the first execution path and the second execution path; the equivalent semantic anchor point is a semantically equivalent operation instruction in the first execution path and the second execution path, including:

[0015] A predefined mapping relationship is established between the execution environment components of the EVM bytecode sequence and the execution environment components of the target machine code sequence.

[0016] Based on the mapping relationship, identify semantically equivalent operation instructions in the first execution path and the second execution path;

[0017] The semantically equivalent operation instructions in the first execution path and the second execution path are determined as the equivalent semantic anchors.

[0018] In some embodiments, matching the first execution path with the second execution path based on the equivalent semantic anchor to determine the matching first execution path and second execution path includes:

[0019] Based on the equivalent semantic anchors, extract the anchor sequence for each of the first execution paths and the anchor sequence for each of the second execution paths;

[0020] The anchor sequence of each first execution path is matched with the anchor sequences of different second execution paths to determine the first execution path and the second execution path that have the same anchor sequence as the matched first execution path and the second execution path.

[0021] In some embodiments, the step of performing semantic equivalence verification on the matching first execution path and second execution path to obtain the verification result includes:

[0022] Construct equivalence constraints between the first execution path and the second execution path; the equivalence constraints include input state equivalence, path constraint equivalence, output state equivalence, and memory state equivalence;

[0023] Based on the equivalence constraint, the semantic equivalence of the matching first execution path and the second execution path is verified by the constraint solver to obtain the verification result.

[0024] In some embodiments, the method further includes:

[0025] When the verification result indicates that the first execution path and the second execution path are not equivalent, the constraint solver generates a corresponding counterexample input; the counterexample input is an input value that proves that the first execution path and the second execution path produce behavioral differences.

[0026] In some embodiments, the method further includes:

[0027] Based on the counterexample input, the EVM bytecode sequence and the target machine code sequence are executed respectively to obtain the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence;

[0028] The execution trajectory of the EVM bytecode sequence is compared with the execution trajectory of the target machine code sequence to determine the instruction location where the behavior first differs.

[0029] Secondly, this embodiment provides a translation verification device for an EVM bytecode compiler, comprising:

[0030] The acquisition module is used to acquire the EVM bytecode sequence and the target machine code sequence compiled based on the EVM bytecode sequence;

[0031] A symbolic execution module is configured to perform symbolic execution on the EVM bytecode sequence and the target machine code sequence respectively, so as to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence;

[0032] The path matching module is used to perform semantic matching between the first execution path and the second execution path to determine the matching first execution path and second execution path;

[0033] The verification module is used to perform semantic equivalence verification on the matching first execution path and second execution path to obtain the verification result.

[0034] Thirdly, this embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the translation and verification method of the EVM bytecode compiler described in the first aspect above.

[0035] Fourthly, this embodiment provides a storage medium storing a computer program that, when executed by a processor, implements the translation and verification method of the EVM bytecode compiler described in the first aspect above.

[0036] Compared with related technologies, the translation verification method, apparatus, and computer device of the EVM bytecode compiler provided in this embodiment obtain an EVM bytecode sequence and a target machine code sequence compiled based on the EVM bytecode sequence; perform symbolic execution on the EVM bytecode sequence and the target machine code sequence respectively to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence; perform semantic matching between the first execution paths and the second execution paths to determine the matching first execution paths and second execution paths; and perform semantic equivalence verification on the matching first execution paths and second execution paths to obtain the verification result. This solves the problem of inefficiently verifying whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent, and achieves efficient verification of whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0037] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0038] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0039] Figure 1 This is a hardware structure block diagram of a terminal device for the translation and verification method of the EVM bytecode compiler provided in an embodiment of this application;

[0040] Figure 2 This is a flowchart of a translation verification method for an EVM bytecode compiler provided in an embodiment of this application;

[0041] Figure 3 This is a flowchart of a path matching method provided in an embodiment of this application;

[0042] Figure 4 This is a flowchart of an embodiment of the equivalent semantic anchor point identification method provided in this application;

[0043] Figure 5 This is a flowchart of a path matching method provided in another embodiment of this application;

[0044] Figure 6 This is a flowchart of a semantic equivalence verification method provided in an embodiment of this application;

[0045] Figure 7 This is a flowchart of a translation verification method for an EVM bytecode compiler provided in another embodiment of this application;

[0046] Figure 8 This is a structural block diagram of the translation and verification device of the EVM bytecode compiler provided in one embodiment of this application.

[0047] In the diagram: 102, processor; 104, memory; 106, transmission device; 108, input / output device; 10, acquisition module; 20, symbolic execution module; 30, path matching module; 40, verification module. Detailed Implementation

[0048] To better understand the purpose, technical solution, and advantages of this application, the application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0049] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these” used in this application do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to these processes, methods, products, or devices. Words such as “connected,” “linked,” and “coupled” used in this application are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. Normally, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," "third," etc., used in this application are merely to distinguish similar objects and do not represent a specific order of objects.

[0050] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. For example, it can run on a terminal. Figure 1 This is a hardware structure block diagram of the terminal for the translation and verification method of the EVM bytecode compiler in this embodiment. (See diagram for example.) Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 and a memory 104 for storing data are also included. The processor 102 may be, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA). The terminal may also include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that… Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0051] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the translation and verification method of the EVM bytecode compiler in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the methods described above. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0052] The transmission device 106 is used to receive or send data via a network. This network includes a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 can be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0053] This embodiment provides a translation verification method for an EVM bytecode compiler. Figure 2 This is a flowchart of the translation verification method of the EVM bytecode compiler in this embodiment, as shown below. Figure 2As shown, the process includes the following steps:

[0054] Step S210: Obtain the EVM bytecode sequence and the target machine code sequence compiled based on the EVM bytecode sequence;

[0055] Specifically, it receives an EVM bytecode sequence and a target machine code sequence compiled from the EVM bytecode sequence. The EVM bytecode sequence typically consists of multiple consecutive instructions, and the target machine code sequence is generated by a virtual machine translator such as a static pre-compiler (Ahead-of-Time Compiler) compiling the EVM bytecode sequence. The types of target machine code sequences include, but are not limited to, x86-64 machine code and arm64 machine code.

[0056] Step S220: Perform symbolic execution on the EVM bytecode sequence and the target machine code sequence respectively to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence.

[0057] Specifically, symbolic execution is performed on the EVM bytecode sequence, symbolizing key states such as contract input, stack, memory, and storage. This allows the symbolic execution engine to systematically explore all possible execution paths, generating corresponding symbolic states and conditional constraints for each path, thereby obtaining all first execution paths of the EVM bytecode sequence. This symbolic execution process can be implemented using Python or tools such as Mythril.

[0058] When execution reaches a branch point (such as an IF statement, JUMP instruction, or function call) and the condition of that branch depends on symbolic input, the symbolic execution engine will fork into a new execution path. Each forked path will proceed along a different instruction sequence, which consists of a series of program counter (PC) values.

[0059] The first execution path set `PathSet_1` is composed of all the first execution paths of the EVM bytecode sequence, where `PathSet_1={(PC_seq,Constraints,SymState)_i}`. Here, `PC_seq` represents the PC sequence, which records the address of each instruction sequentially passed during program execution, precisely depicting the control flow of the code; `Constraints` represents the constraints, which are closely related to the PC sequence. When a path forks, the symbolic execution engine adds constraints to each new path, and satisfying these constraints is a prerequisite for the program to execute along that path; `SymState` represents the symbolic state, such as the program's stack, memory, and storage, which is dynamically updated as instructions are executed along the PC sequence.

[0060] Furthermore, symbolic execution is performed on the target machine code sequence generated by the virtual machine compiler to explore all possible execution paths, thereby obtaining all secondary execution paths of the target machine code sequence. It should be noted that, to ensure that symbolic execution correctly simulates the behavior of the compiler-generated machine code, the virtual machine compiler's state regarding the stack, memory, etc., is modeled in advance. For example, the virtual machine compiler fixes a certain register to store the top of the EVM stack. Based on this, one can choose to implement symbolic execution of the target machine code sequence independently or utilize frameworks such as angr to implement symbolic execution.

[0061] The second execution path set `PathSet_2` is composed of all the second execution paths of the target machine code sequence, where `PathSet_2={(RIP_seq,Constraints,SymState)_i}`. Here, `RIP_seq` represents the instruction pointer sequence; `Constraints` represents the constraints; and `SymState` represents the symbolic state.

[0062] Understandably, symbolic execution automatically explores all reachable execution paths without requiring manual test case construction. Within a preset path depth limit, it theoretically achieves 100% coverage of all reachable paths, effectively overcoming the shortcomings of insufficient coverage in existing testing methods. Furthermore, symbolic execution avoids actual code execution during analysis, preventing runtime overhead and contributing to improved verification efficiency.

[0063] Step S230: Semantic matching is performed between the first execution path and the second execution path to determine the matching first execution path and second execution path;

[0064] Semantic matching is performed between the first execution path and the second execution path to determine the matching first and second execution paths. Specifically, this can be achieved by: identifying semantically equivalent operation instructions in the first and second execution paths, i.e., equivalent semantic anchors between the first and second execution paths; and matching the first and second execution paths based on these equivalent semantic anchors to determine the matching first and second execution paths; or, analyzing whether the control flow topologies of the first and second execution paths are similar, and checking whether the symbol values ​​used to simulate a specific EVM component remain consistent throughout the path, thereby determining the matching first and second execution paths.

[0065] Step S240: Perform semantic equivalence verification on the matching first execution path and second execution path to obtain the verification result.

[0066] Specifically, equivalence constraints are constructed between the first and second execution paths. These constraints include input state equivalence, path constraint equivalence, output state equivalence, and memory state equivalence. Based on these equivalence constraints, a constraint solver is used to perform semantic equivalence verification on the matching first and second execution paths to obtain the verification results. In other embodiments, an equivalent initial state can be used as the verification starting point. The operation steps of the EVM path and the corresponding instruction sequence with the target machine code sequence are simulated. After each step, the latest state of both is checked to see if it satisfies a predefined correspondence. This process proceeds step-by-step throughout the entire execution path, thereby timely and accurately locating the specific instruction node or state position of the semantic divergence.

[0067] Understandably, if the semantic equivalence verification between the first and second execution paths passes, it indicates that the virtual machine compiler compiled correctly; conversely, if the semantic equivalence verification between the first and second execution paths fails, it indicates that the virtual machine compiler compiled incorrectly, and the compilation process may have introduced errors or changed program behavior. Furthermore, in the case of one-to-many path matching, semantic equivalence verification needs to be performed on all matching execution paths. If all matching execution paths pass the semantic equivalence verification, it can be determined that the compiler compiled correctly.

[0068] Therefore, this embodiment is based on Translation Validation. Symbolic execution techniques are used to perform symbolic analysis on the EVM bytecode sequence and the compiled target machine code sequence, extracting the execution path and verifying their semantic consistency. Translation validation verifies whether the two programs are semantically equivalent or satisfy refinement relations after being translated from one program representation (e.g., EVM bytecode) to another (e.g., x86-64 machine code), thus proving the correctness of the translation process. It uses formal methods (e.g., SMT solvers) for program-level verification, proving the correctness of the translation for all inputs without relying on test cases. Compared to white-box verification, translation validation treats the compiler as a black box, focusing only on the semantic equivalence of input and output, without delving into compiler implementation details. Therefore, it has high verification efficiency, low development cost, and is insensitive to subsequent changes in the compiler implementation.

[0069] Existing compiler verification methods construct limited test inputs, execute the original EVM bytecode sequence and the compiled machine code sequence respectively, and compare the output results to determine consistency. However, this method is difficult to cover all branch scenarios and cannot efficiently verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0070] Compared to existing technologies, this application obtains an EVM bytecode sequence and a target machine code sequence compiled from the EVM bytecode sequence; performs symbolic execution on both the EVM bytecode sequence and the target machine code sequence to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence; performs semantic matching on the first and second execution paths to determine matching first and second execution paths; and performs semantic equivalence verification on the matching first and second execution paths to obtain verification results. Based on this, symbolic execution technology is used to perform symbolic analysis on the EVM bytecode sequence and the compiled target machine code sequence to extract execution paths. Combined with path matching and equivalence verification, the semantic consistency of the two is accurately verified, thus solving the problem of inefficiently verifying whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent, and achieving efficient verification of whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent. Moreover, the entire verification process requires no manual intervention. It is fully automated from input of EVM bytecode sequence / target machine code sequence to output of verification results. There is no need to write formal proof code, which significantly lowers the technical threshold. It can also be integrated into the compiler's CI / CD process to achieve continuous verification.

[0071] In some of these embodiments, such as Figure 3 As shown, step S230, which involves semantically matching the first execution path with the second execution path to determine the matching first and second execution paths, includes the following steps:

[0072] Step S231: Determine the equivalent semantic anchor point between the first execution path and the second execution path; the equivalent semantic anchor point is the semantically equivalent operation instruction in the first execution path and the second execution path;

[0073] Step S232: Based on the equivalent semantic anchor, the first execution path and the second execution path are matched to determine the matching first execution path and second execution path.

[0074] Specifically, semantically equivalent operation instructions in the first and second execution paths are identified and used as equivalent semantic anchors between them. Taking x86-64 machine code as an example, the correspondence between equivalent semantic anchors includes "EVM storage operation (SSTORE)". "x86-64 memory write operations", "EVM log events (LOG)" "x86-64 specific function calls", "EVM return (RETURN)" x86-64 Return Instruction (RET) and EVM External Call (CALL) "x86-64 function calls", etc.

[0075] Furthermore, based on the aforementioned equivalent semantic anchors, each first execution path in the first execution path set `PathSet_1` is matched with each second execution path in the second execution path set `PathSet_2` to determine the matching first and second execution paths. For example, if two paths contain the same and sequentially corresponding anchor sequences, they are determined to be matching paths; or, predefined key semantic anchors (such as operations involving contract storage SSTORE or external call CALL), when two paths contain the same key anchor subsequences in the same order, they are determined to be matching paths.

[0076] It should be noted that the matching relationship may be one-to-many, meaning a single first execution path matches multiple second execution paths. For example, a single EVM instruction matches multiple corresponding x86 instructions. In this case, the matching relationship between the first execution path and all corresponding second execution paths will be saved.

[0077] This embodiment identifies equivalent semantic anchor points between the first and second execution paths. Based on these anchor points, the first and second execution paths are matched, enabling accurate path matching based on control flow structure and semantic anchor points. This not only reduces the number of path pairs requiring verification, improving verification efficiency, but also establishes an accurate comparison foundation for subsequent semantic equivalence verification. More importantly, by identifying semantically equivalent anchor operations in the two instruction sets, a correspondence can be established through anchor points even when the instruction sequences are completely different, solving the matching problem between instructions of different granularities.

[0078] In some of these embodiments, such as Figure 4 As shown, step S231 involves determining the equivalent semantic anchor point between the first execution path and the second execution path; the equivalent semantic anchor point is a semantically equivalent operation instruction in the first execution path and the second execution path, including the following steps:

[0079] Step S2311: Predefine the mapping relationship between the execution environment components of the EVM bytecode sequence and the execution environment components of the target machine code sequence;

[0080] Step S2312: Based on the mapping relationship, identify semantically equivalent operation instructions in the first execution path and the second execution path;

[0081] Step S2313: Determine semantically equivalent operation instructions in the first execution path and the second execution path as equivalent semantic anchors.

[0082] Specifically, the EVM bytecode sequence and the target machine code sequence are pre-matched structurally to define the mapping relationship between the execution environment components of the EVM bytecode sequence and the execution environment components of the target machine code sequence, thereby providing a unified semantic analysis framework for the two heterogeneous execution environments. Taking x86-64 machine code as an example, the defined mapping relationships include "EVM stack top → x86 register", "EVM stack length → x86 register", "EVM memory → x86 heap memory", "EVM storage → a certain x86 data structure", "EVM input → a certain x86 data structure", etc.

[0083] Furthermore, based on the defined mapping relationship, semantically equivalent operation instructions in the first and second execution paths are identified, and these semantically equivalent operation instructions are determined as equivalent semantic anchors. For example, based on the mapping relationship "EVM storage → a certain data structure in x86", the EVM's SSTORE instruction can be accurately associated with memory write operations in x86-64, thus forming an equivalent semantic anchor.

[0084] In this embodiment, a mapping relationship is predefined between the execution environment components of the EVM bytecode sequence and the execution environment components of the target machine code sequence. Based on the mapping relationship, semantically equivalent operation instructions in the first execution path and the second execution path are identified, and semantically equivalent operation instructions in the first execution path and the second execution path are determined as equivalent semantic anchors. Thus, through the precise correspondence of anchors, efficient filtering and mapping between paths can be achieved, which helps to improve verification efficiency.

[0085] In some of these embodiments, such as Figure 5 As shown, step S232, which matches the first execution path with the second execution path based on equivalent semantic anchors to determine the matching first and second execution paths, includes the following steps:

[0086] Step S2321: Based on equivalent semantic anchors, extract the anchor sequence of each first execution path and the anchor sequence of each second execution path;

[0087] Step S2322: Match the anchor sequence of each first execution path with the anchor sequences of different second execution paths, and determine the first execution path and the second execution path with the same anchor sequence as the matched first execution path and the second execution path.

[0088] Specifically, each execution path in the first and second execution path sets is traversed separately. During the traversal, all operation instructions marked as equivalent semantic anchors (such as SSTORE, CALL, etc.) in the execution path are identified and arranged according to the order in which the operation instructions appear in the execution flow, thereby obtaining the anchor sequence corresponding to each path. This anchor sequence preserves the core semantic skeleton of the corresponding execution path at the control flow level.

[0089] After obtaining the anchor sequence of all paths, the matching relationship between the first execution path and the second execution path is established by comparing the anchor sequence. In practice, the anchor sequence of each first execution path is compared with each anchor sequence in the set of second execution paths, and the matching process is completed by using strategies such as precise sequence matching or fuzzy matching based on edit distance, depending on the actual needs.

[0090] In the case of precise sequence matching, if two paths are found to have the same anchor sequence (i.e., all anchor types and their order of appearance are the same), the first execution path and the second execution path are determined to be a matching path pair. In the case of fuzzy matching based on edit distance, the minimum number of editing operations (including inserting, deleting, or replacing anchors) required to convert one anchor sequence into another is calculated. If the edit distance between the two sequences is less than a preset threshold, they are determined to be a matching path. This effectively addresses the legitimate instruction scheduling or redundant operations introduced by compiler optimizations, and significantly improves the robustness and fault tolerance of the matching process.

[0091] In this embodiment, based on equivalent semantic anchors, the anchor sequence of each first execution path and the anchor sequence of each second execution path are extracted. The anchor sequence of each first execution path is matched with the anchor sequences of different second execution paths, thereby determining that the first execution path and the second execution path with the same anchor sequence are the matched first execution path and the second execution path. This enables the handling of structural differences caused by compiler optimizations (such as instruction fusion, loop unrolling, etc.).

[0092] In some of these embodiments, such as Figure 6 As shown, step S240 involves performing semantic equivalence verification on the matching first and second execution paths to obtain the verification result, including the following steps:

[0093] Step S241: Construct equivalence constraints between the first execution path and the second execution path; equivalence constraints include input state equivalence, path constraint equivalence, output state equivalence, and memory state equivalence.

[0094] Step S242: Based on equivalence constraints, the semantic equivalence of the matching first execution path and second execution path is verified by the constraint solver to obtain the verification result.

[0095] In this embodiment, equivalence constraints between the first execution path and the second execution path are pre-constructed. These equivalence constraints include input state equivalence, path constraint equivalence, output state equivalence, and memory state equivalence. The x86-64 machine code is used as an example for illustration:

[0096] 1. Input state equivalence: This indicates the consistency between the symbolic input (evm_input) of the EVM layer and the symbolic input variables (x86_input) of the x86 layer. The specific execution is as follows:

[0097] for (evm_input,x86_input) in input_mapping:

[0098] constraints.append(evm_input == x86_input)

[0099] Among them, input_mapping defines the correspondence between the symbolic inputs of the EVM layer and the symbolic input variables of the x86 layer.

[0100] 2. Path constraint equivalence is used to indicate the consistency between the execution path constraints (evm_path_constraint) of the EVM layer and the execution path constraints (x86_path_constraint) of the x86 layer. The specific execution is as follows:

[0101] evm_path_constraint = evm_path.get_constraint()

[0102] x86_path_constraint = x86_path.get_constraint()

[0103] constraints.append(evm_path_constraint == x86_path_constraint)

[0104] 3. Output state equivalence, used to indicate the consistency between the output state of the EVM layer (evm_output) and the output state of the x86 layer (x86_output). The specific execution is as follows:

[0105] for (evm_output,x86_output) in output_mapping:

[0106] constraints.append(evm_output == x86_output)

[0107] Among them, output_mapping defines the correspondence between the output states of the EVM layer and the output states of the x86 layer.

[0108] 4. Path constraint equivalence is used to indicate the consistency between the memory state (evm_storage) of the EVM layer and the storage state (x86_memory) of the x86 layer. The specific execution is as follows:

[0109] for (evm_storage,x86_memory) in storage_mapping:

[0110] constraints.append(evm_storage == x86_memory)

[0111] Among them, storage_mapping defines the correspondence between the memory state of the EVM layer and the storage state of the x86 layer.

[0112] Furthermore, based on equivalence constraints, semantic equivalence verification is performed on the matching first and second execution paths using constraint solvers (such as the Z3 solver or the Boolector solver) to obtain the verification results. The Z3 solver is preferably used, as it can process multiple matching path pairs in parallel, thereby improving verification efficiency.

[0113] In this embodiment, equivalence constraints are constructed between the first execution path and the second execution path. The equivalence constraints include input state equivalence, path constraint equivalence, output state equivalence, and memory state equivalence. Based on the equivalence constraints, the constraint solver performs semantic equivalence verification on the matching first and second execution paths to obtain the verification results. This enables fine-grained verification of the program's final output, intermediate states, and memory layout, accurately identifying subtle semantic differences caused by compilation optimizations (such as loop unrolling and instruction reordering) or cross-hardware architecture (such as x86 and ARM) execution.

[0114] In some embodiments, the translation verification method of the above-mentioned EVM bytecode compiler further includes the following steps:

[0115] When the verification results indicate that the first execution path and the second execution path are not equivalent, the constraint solver generates a corresponding counterexample input; the counterexample input is an input value that proves that the first execution path and the second execution path produce behavioral differences.

[0116] In this embodiment, when the verification result indicates that the matching first execution path and second execution path are not equivalent, a counterexample input is obtained by solving the constraint solver. The counterexample input is an input value that can trigger a behavioral difference between the first execution path and the second execution path. For example, the counterexample input is a=-1, b=0. Under this input, the execution results of the first execution path and the second execution path are different.

[0117] Taking constraint solving using the Z3 solver as an example, the specific execution is as follows:

[0118] pythonsolver = z3.Solver()

[0119] #Add equivalence constraints

[0120] equivalence_constraint = encode_equivalence(path_evm,path_x86)

[0121] solver.add(equivalence_constraint)

[0122] #In cases of inequivalence, try to find counterexamples.

[0123] solver.add(Not(equivalence_constraint))

[0124] if solver.check() == z3.sat:

[0125] model = solver.model()

[0126] counterexample = extract_input(model)

[0127] return (False, counterexample)

[0128] else:

[0129] #Verification passed, the two paths are equivalent.

[0130] return (True,None)

[0131] In this embodiment, when the verification results indicate that the first execution path and the second execution path are not equivalent, the constraint solver generates counterexample inputs, which helps to quickly locate the instruction location that causes the behavioral difference.

[0132] In some embodiments, the translation verification method of the above-mentioned EVM bytecode compiler further includes the following steps:

[0133] Based on the counterexample input, the EVM bytecode sequence and the target machine code sequence are executed respectively to obtain the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence.

[0134] The execution trajectory of the EVM bytecode sequence is compared with the execution trajectory of the target machine code sequence to determine the instruction location where the behavior first differs.

[0135] Specifically, based on the counterexample input from the constraint solver output, the EVM bytecode sequence and the target machine code sequence are executed respectively to obtain the corresponding execution trajectories. The execution trajectory of the EVM bytecode sequence includes the opcode sequence, stack state changes, memory read / write records, and storage state updates; the execution trajectory of the target machine code sequence includes the instruction sequence, register value changes, memory access records, and flag state changes.

[0136] The execution trajectory of the EVM bytecode sequence is compared with the execution trajectory of the target machine code sequence. By comparing the corresponding state changes of each instruction, the location of the instruction that first caused the behavioral difference is accurately located, and the location information is recorded simultaneously. This includes the location of the erroneous EVM instruction, the corresponding erroneous machine code instruction, the specific input that caused the difference, and a description of the state difference, providing a precise basis for subsequent root cause analysis. In practice, a corresponding error report can be output based on the above location information.

[0137] In this embodiment, based on counterexample input, the EVM bytecode sequence and the target machine code sequence are executed respectively to obtain the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence. Then, the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence are compared to determine the instruction position where the behavior first differs, thereby achieving accurate error location and providing a detailed error report to facilitate rapid repair of compiler vulnerabilities.

[0138] The present embodiment will be described and explained below through specific examples.

[0139] Reference Figure 7 As shown, the input is an EVM bytecode sequence and an x86-64 machine code sequence compiled based on the EVM bytecode sequence. Symbolic execution is performed on the EVM bytecode sequence and the x86-64 machine code sequence respectively to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the x86-64 machine code sequence.

[0140] A mapping relationship is predefined between the execution environment components of the EVM bytecode sequence and the execution environment components of the target machine code sequence. Based on this mapping relationship, semantically equivalent operation instructions in the first and second execution paths are identified, and these semantically equivalent operation instructions are determined as equivalent semantic anchors. Based on the equivalent semantic anchors, the anchor sequence of each first execution path and the anchor sequence of each second execution path are extracted. The anchor sequence of each first execution path is matched with the anchor sequences of different second execution paths, and the first and second execution paths with the same anchor sequence are determined as matched first and second execution paths.

[0141] Furthermore, equivalence constraints are constructed between the first execution path and the second execution path. These equivalence constraints include input state equivalence, path constraint equivalence, output state equivalence, and memory state equivalence. Based on these equivalence constraints, a constraint solver is used to perform semantic equivalence verification on the matching first and second execution paths, and the verification results are output.

[0142] Specifically, when the verification result indicates that the first execution path and the second execution path are equivalent, it means that the compiler has compiled correctly. When the verification result indicates that the first execution path and the second execution path are not equivalent, the constraint solver generates corresponding counterexample inputs. The counterexample inputs are input values ​​that prove that the first execution path and the second execution path produce behavioral differences. Based on the counterexample inputs, the EVM bytecode sequence and the target machine code sequence are executed respectively to obtain the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence. By comparing the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence, the instruction position that first produces behavioral differences is determined.

[0143] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0144] This embodiment also provides a translation and verification device for an EVM bytecode compiler, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. The terms "module," "unit," "subunit," etc., used below can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0145] Figure 8 This is a structural block diagram of the translation and verification device of the EVM bytecode compiler in this embodiment, as shown below. Figure 8As shown, the device includes:

[0146] Module 10 is used to acquire the EVM bytecode sequence and the target machine code sequence compiled based on the EVM bytecode sequence;

[0147] Symbolic execution module 20 is used to perform symbolic execution on the EVM bytecode sequence and the target machine code sequence respectively, so as to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence;

[0148] The path matching module 30 is used to semantically match the first execution path with the second execution path to determine the matching first execution path and second execution path;

[0149] The verification module 40 is used to perform semantic equivalence verification on the matching first execution path and second execution path to obtain the verification result.

[0150] The apparatus provided in this embodiment obtains an EVM bytecode sequence and a target machine code sequence compiled from the EVM bytecode sequence; it performs symbolic execution on the EVM bytecode sequence and the target machine code sequence respectively to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence; it performs semantic matching on the first execution paths and the second execution paths to determine the matching first execution paths and second execution paths; it performs semantic equivalence verification on the matching first execution paths and second execution paths to obtain the verification results. This solves the problem of not being able to efficiently verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent, and achieves efficient verification of whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0151] In some embodiments, the path matching module 30 is further configured to determine equivalent semantic anchors between the first execution path and the second execution path; the equivalent semantic anchors are semantically equivalent operation instructions in the first execution path and the second execution path; based on the equivalent semantic anchors, the first execution path and the second execution path are matched to determine the matching first execution path and second execution path.

[0152] In some embodiments, the path matching module 30 is further configured to predefine the mapping relationship between the execution environment components of the EVM bytecode sequence and the execution environment components of the target machine code sequence; based on the mapping relationship, identify semantically equivalent operation instructions in the first execution path and the second execution path; and determine the semantically equivalent operation instructions in the first execution path and the second execution path as equivalent semantic anchors.

[0153] In some embodiments, the path matching module 30 is further configured to extract the anchor sequence of each first execution path and the anchor sequence of each second execution path based on equivalent semantic anchors; match the anchor sequence of each first execution path with the anchor sequences of different second execution paths, and determine the first execution path and the second execution path with the same anchor sequence as the matched first execution path and the second execution path.

[0154] In some embodiments, the verification module 40 is further configured to construct equivalence constraints between the first execution path and the second execution path; the equivalence constraints include input state equivalence, path constraint equivalence, output state equivalence, and memory state equivalence; based on the equivalence constraints, the matching first execution path and the second execution path are semantically equivalence verified by the constraint solver to obtain the verification result.

[0155] In some embodiments, the verification module 40 is further configured to generate a corresponding counterexample input through the constraint solver when the verification result indicates that the matching first execution path and the second execution path are not equivalent; the counterexample input is an input value that proves that the first execution path and the second execution path produce behavioral differences.

[0156] In some of these embodiments, in Figure 7 Based on this, the device also includes a positioning module, which is used to execute the EVM bytecode sequence and the target machine code sequence respectively based on the counterexample input to obtain the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence; and compare the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence to determine the instruction position where the behavior difference first occurs.

[0157] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0158] This embodiment also provides a computer device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0159] Optionally, the computer device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0160] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0161] S1, obtain the EVM bytecode sequence and the target machine code sequence compiled based on the EVM bytecode sequence;

[0162] S2, perform symbolic execution on the EVM bytecode sequence and the target machine code sequence respectively to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence;

[0163] S3, perform semantic matching between the first execution path and the second execution path to determine the matching first execution path and second execution path;

[0164] S4. Perform semantic equivalence verification on the matching first and second execution paths to obtain the verification results.

[0165] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0166] Furthermore, in conjunction with the translation verification method of the EVM bytecode compiler provided in the above embodiments, this embodiment can also provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any one of the translation verification methods of the EVM bytecode compiler in the above embodiments.

[0167] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0168] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0169] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0170] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A translation verification method for an EVM bytecode compiler, characterized in that, include: Obtain the EVM bytecode sequence and the target machine code sequence compiled based on the EVM bytecode sequence; Symbolic execution is performed on the EVM bytecode sequence and the target machine code sequence respectively to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence; The first execution path and the second execution path are semantically matched to determine the matching first execution path and the second execution path; The semantic equivalence of the matching first execution path and second execution path is verified to obtain the verification results.

2. The translation verification method of the EVM bytecode compiler according to claim 1, characterized in that, The step of semantically matching the first execution path with the second execution path to determine the matching first execution path and second execution path includes: Determine the equivalent semantic anchor point between the first execution path and the second execution path; the equivalent semantic anchor point is the semantically equivalent operation instruction in the first execution path and the second execution path. Based on the equivalent semantic anchor, the first execution path and the second execution path are matched to determine the matching first execution path and the second execution path.

3. The translation verification method of the EVM bytecode compiler according to claim 2, characterized in that, The step of determining the equivalent semantic anchor point between the first execution path and the second execution path; the equivalent semantic anchor point is a semantically equivalent operation instruction in the first execution path and the second execution path, including: A predefined mapping relationship is established between the execution environment components of the EVM bytecode sequence and the execution environment components of the target machine code sequence. Based on the mapping relationship, identify semantically equivalent operation instructions in the first execution path and the second execution path; The semantically equivalent operation instructions in the first execution path and the second execution path are determined as the equivalent semantic anchors.

4. The translation verification method of the EVM bytecode compiler according to claim 2, characterized in that, The step of matching the first execution path with the second execution path based on the equivalent semantic anchor to determine the matching first execution path and second execution path includes: Based on the equivalent semantic anchors, extract the anchor sequence for each of the first execution paths and the anchor sequence for each of the second execution paths; The anchor sequence of each first execution path is matched with the anchor sequences of different second execution paths to determine the first execution path and the second execution path that have the same anchor sequence as the matched first execution path and the second execution path.

5. The translation verification method of the EVM bytecode compiler according to claim 1, characterized in that, The step of performing semantic equivalence verification on the matching first execution path and second execution path to obtain the verification result includes: Construct equivalence constraints between the first execution path and the second execution path; the equivalence constraints include input state equivalence, path constraint equivalence, output state equivalence, and memory state equivalence; Based on the equivalence constraint, the semantic equivalence of the matching first execution path and the second execution path is verified by the constraint solver to obtain the verification result.

6. The translation verification method of the EVM bytecode compiler according to claim 5, characterized in that, The method further includes: When the verification result indicates that the first execution path and the second execution path are not equivalent, the constraint solver generates a corresponding counterexample input; the counterexample input is an input value that proves that the first execution path and the second execution path produce behavioral differences.

7. The translation verification method of the EVM bytecode compiler according to claim 6, characterized in that, The method further includes: Based on the counterexample input, the EVM bytecode sequence and the target machine code sequence are executed respectively to obtain the execution trajectory of the EVM bytecode sequence and the execution trajectory of the target machine code sequence; The execution trajectory of the EVM bytecode sequence is compared with the execution trajectory of the target machine code sequence to determine the instruction location where the behavior first differs.

8. A translation verification device for an EVM bytecode compiler, characterized in that, include: The acquisition module is used to acquire the EVM bytecode sequence and the target machine code sequence compiled based on the EVM bytecode sequence; A symbolic execution module is configured to perform symbolic execution on the EVM bytecode sequence and the target machine code sequence respectively, so as to obtain all first execution paths of the EVM bytecode sequence and all second execution paths of the target machine code sequence; The path matching module is used to perform semantic matching between the first execution path and the second execution path to determine the matching first execution path and second execution path; The verification module is used to perform semantic equivalence verification on the matching first execution path and second execution path to obtain the verification result.

9. A computer device, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the steps of the translation verification method of the EVM bytecode compiler according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the translation verification method of the EVM bytecode compiler according to any one of claims 1 to 7.

Images