Translation verification method and device for block chain virtual machine compiler and computer equipment

Abstract

The invention relates to a translation verification method and device of a block chain virtual machine compiler and computer equipment, and the translation verification method of the block chain virtual machine compiler comprises the following steps: converting an input EVM byte code sequence into a corresponding first intermediate representation; the first intermediate representation is a general semantic mapping representation of an EVM byte code sequence; compiling the EVM byte code sequence into a target machine code sequence through a to-be-verified compiler; converting the target machine code sequence into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence; and performing semantic equivalence verification on the first intermediate representation and the second intermediate representation 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 verified is solved, and whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent or not is verified.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to translation verification methods, apparatus, and computer equipment for blockchain virtual machine compilers. Background Technology

[0002] During the execution of smart contracts, a blockchain virtual machine compiler (such as an AOT compiler) is typically used to compile the Ethereum Virtual Machine (EVM) bytecode sequence into a native machine code sequence for a specific target architecture (such as x86-64 or arm64 machine code). However, this compilation process can introduce biases, causing the generated machine code sequence to behave inconsistently with the original EVM bytecode sequence. Therefore, verifying the correctness of the compilation results is crucial.

[0003] Existing verification methods construct finite test inputs, execute the original EVM bytecode sequence and the compiled machine code sequence respectively, and compare the output results to determine whether their behavior is consistent. However, this method cannot 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 it is impossible to verify whether the compiled machine code sequence is semantically equivalent to the original EVM bytecode sequence in related technologies. Summary of the Invention

[0005] This embodiment provides a translation verification method, apparatus, and computer device for a blockchain virtual machine compiler to solve the problem in related technologies that it is impossible to 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 a blockchain virtual machine compiler, including:

[0007] The input EVM bytecode sequence is converted into a corresponding first intermediate representation; the first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence.

[0008] The EVM bytecode sequence is compiled into a target machine code sequence using the compiler to be verified.

[0009] The target machine code sequence is converted into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence.

[0010] Semantic equivalence verification is performed on the first intermediate representation and the second intermediate representation to obtain the verification result.

[0011] In some embodiments, converting the input EVM bytecode sequence into a corresponding first intermediate representation includes:

[0012] The input EVM bytecode sequence is converted into a corresponding EVM intermediate representation; the EVM intermediate representation is a structured representation that preserves the stack-based operation semantics in the EVM bytecode sequence.

[0013] Convert the EVM intermediate representation into the first intermediate representation.

[0014] In some embodiments, converting the EVM intermediate representation into the first intermediate representation includes:

[0015] Based on pre-built stack-based operation semantic mapping, execution state mapping, and instruction translation rules, the EVM intermediate representation is converted into the first intermediate representation;

[0016] Wherein, the stack-based operation semantic mapping indicates the correspondence between the stack operations of the EVM intermediate representation and the register operations of the first intermediate representation; the execution state mapping indicates the correspondence between the execution context of the EVM intermediate representation and the data structure of the first intermediate representation; and the instruction translation rule indicates the correspondence between the operation instructions of the EVM intermediate representation and the operation instructions of the first intermediate representation.

[0017] In some embodiments, converting the target machine code sequence into a corresponding second intermediate representation includes:

[0018] The target machine code sequence is subjected to binary enhancement processing to obtain the corresponding second intermediate representation; the target machine code sequence is a binary machine code file, an executable file, or assembly code.

[0019] In some embodiments, the semantic equivalence verification of the first intermediate representation and the second intermediate representation includes:

[0020] The semantic equivalence of the first intermediate representation and the second intermediate representation is verified using a semantic verification tool based on constraint solvers.

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

[0022] When the verification result indicates that the semantic equivalence between the first intermediate representation and the second intermediate representation fails, the semantic verification tool generates a corresponding counterexample input; the counterexample input is an input value that proves that the first intermediate representation and the second intermediate representation are semantically inequivalent.

[0023] In some embodiments, the first intermediate representation and the second intermediate representation are LLVM intermediate representations.

[0024] Secondly, this embodiment provides a translation verification device for a blockchain virtual machine compiler, comprising:

[0025] The first conversion module is used to convert the input EVM bytecode sequence into a corresponding first intermediate representation; the first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence.

[0026] A compilation module is used to compile the EVM bytecode sequence into a target machine code sequence using a compiler to be verified.

[0027] The second conversion module is used to convert the target machine code sequence into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence.

[0028] The verification module is used to perform semantic equivalence verification on the first intermediate representation and the second intermediate representation to obtain the verification result.

[0029] 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 blockchain virtual machine compiler described in the first aspect above.

[0030] 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 blockchain virtual machine compiler described in the first aspect above.

[0031] Compared with related technologies, the blockchain virtual machine compiler translation verification method, apparatus, and computer device provided in this embodiment convert the input EVM bytecode sequence into a corresponding first intermediate representation; the first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence; the compiler to be verified compiles the EVM bytecode sequence into a target machine code sequence; the target machine code sequence is converted into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence; semantic equivalence verification is performed on the first intermediate representation and the second intermediate representation to obtain the verification result. This solves the problem of not being able to verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent, and realizes the verification of whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0032] 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

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

[0034] Figure 1 This is a hardware structure block diagram of a terminal device for a blockchain virtual machine compiler translation and verification method provided in one embodiment of this application;

[0035] Figure 2 This is a flowchart of a translation verification method for a blockchain virtual machine compiler provided in one embodiment of this application;

[0036] Figure 3 This is a flowchart of an embodiment of the EVM bytecode sequence conversion method provided in this application;

[0037] Figure 4 This is a flowchart of a target machine code sequence conversion method provided in an embodiment of this application;

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

[0039] Figure 6 This is a flowchart illustrating a translation and verification method for a blockchain virtual machine compiler provided in one embodiment of this application;

[0040] Figure 7 This is a structural block diagram of a translation and verification device for a blockchain virtual machine compiler provided in one embodiment of this application.

[0041] In the diagram: 102, processor; 104, memory; 106, transmission device; 108, input / output device; 10, first conversion module; 20, compilation module; 30, second conversion module; 40, verification module. Detailed Implementation

[0042] 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.

[0043] 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.

[0044] 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 blockchain virtual machine 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.

[0045] 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 blockchain virtual machine 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 above-described method. 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.

[0046] 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.

[0047] This embodiment provides a translation verification method for a blockchain virtual machine compiler. Figure 2 This is a flowchart of the translation and verification method of the blockchain virtual machine compiler in this embodiment, as shown below. Figure 2 As shown, the process includes the following steps:

[0048] Step S210: Convert the input EVM bytecode sequence into the corresponding first intermediate representation; the first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence.

[0049] Specifically, the EVM bytecode sequence is the code before compilation, consisting of multiple consecutive instructions. The input EVM bytecode sequence is converted into a corresponding first intermediate representation, which is a general semantic mapping representation of the EVM bytecode sequence. The first intermediate representation can be a Low Level Virtual Machine Intermediate Representation (LLVM IR) or other custom intermediate representations, as long as it can achieve a complete semantic mapping of the EVM bytecode sequence and meet the requirements of subsequent processing. In this embodiment, the specific form of the first intermediate representation is not limited; the implementation methods listed above are merely illustrative examples.

[0050] It should be further explained that the conversion of the EVM bytecode sequence to the first intermediate representation can be achieved in the following ways: directly converting the EVM bytecode sequence to the first intermediate representation; or, converting the input EVM bytecode sequence to the EVM intermediate representation in advance, wherein the EVM intermediate representation is a structured representation that preserves the stack operation semantics in the EVM bytecode sequence, and then further converting the EVM intermediate representation to the first intermediate representation.

[0051] Step S220: Compile the EVM bytecode sequence into the target machine code sequence using the compiler to be verified;

[0052] Specifically, the EVM bytecode sequence is input into a compiler to be verified. This compiler can be any compiler capable of generating machine code sequences, such as a static preprocessor (Ahead-of-Time Compiler). The compiler then compiles the EVM bytecode sequence to generate the corresponding target machine code sequence. The target machine code sequence is the compiled code, and its categories include, but are not limited to, x86-64 machine code and arm64 machine code.

[0053] Step S230: Convert the target machine code sequence into the corresponding second intermediate representation; the second intermediate representation is the general semantic mapping representation of the target machine code sequence;

[0054] Specifically, the compiled target machine code sequence is converted into a corresponding second intermediate representation, which is a general semantic mapping representation of the target machine code sequence. The second intermediate representation can be LLVM IR or other custom intermediate representation formats.

[0055] It is understandable that the second intermediate representation preferably adopts the same form as the first intermediate representation, providing a unified processing benchmark for subsequent processes such as semantic equivalence verification. In this way, different levels of representation (EVM bytecode sequence and target machine code sequence) are uniformly mapped to the intermediate representation layer.

[0056] Step S240: Perform semantic equivalence verification on the first intermediate representation and the second intermediate representation to obtain the verification result.

[0057] Specifically, after obtaining the first intermediate representation and the second intermediate representation, semantic equivalence verification is performed on the first intermediate representation and the second intermediate representation. This embodiment supports multiple verification implementation methods, which can be flexibly selected according to the actual application scenario. Specifically, these include the following paths: using semantic verification tools to perform semantic equivalence verification on the first intermediate representation and the second intermediate representation; or, verifying their semantic consistency by converting the abstract syntax trees or control flow graphs of the two intermediate representations into formal models and performing automated mathematical reasoning.

[0058] Understandably, if the semantic equivalence verification of the first and second intermediate representations passes, it indicates that the compiler has compiled correctly; conversely, if the semantic equivalence verification of the first and second intermediate representations fails, it indicates that the compiler has compiled incorrectly, and the compilation process may introduce errors or change the program behavior.

[0059] Therefore, a formal verification method based on translation validation for the blockchain virtual machine compiler is adopted. This method converts both the pre- and post-compilation code into a unified intermediate representation and performs semantic equivalence verification. 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 boasts high verification efficiency, low development costs, and insensitivity to subsequent changes in the compiler implementation.

[0060] Existing verification methods construct finite test inputs, execute the original EVM bytecode sequence and the compiled machine code sequence respectively, and compare the output results to determine whether their behavior is consistent. However, this method cannot verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0061] Compared to existing technologies, this application converts the input EVM bytecode sequence into a corresponding first intermediate representation; the first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence; the EVM bytecode sequence is compiled into a target machine code sequence using a compiler to be verified; the target machine code sequence is then converted into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence; semantic equivalence verification is performed on the first and second intermediate representations to obtain the verification result. Based on this, by uniformly mapping representations at different levels (EVM bytecode sequence and target machine code sequence) to an intermediate representation layer, semantic equivalence verification across abstraction levels is achieved, solving the problem of not being able to verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent, thus realizing the verification of whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent. Furthermore, by designing a modular, scalable, and generalized verification framework, it possesses the ability to flexibly adapt to various blockchain virtual machines and different target hardware architectures, significantly improving the universality and scalability of the verification scheme.

[0062] Furthermore, this application does not require complete formal modeling of the compiler implementation, which significantly reduces the technical threshold and workload of verification work. Moreover, it does not require building a verification framework from scratch. Relying on the unified semantic benchmark of the intermediate representation layer, it can be adapted to any compiler that can generate machine code sequences, which significantly broadens the applicability of the solution.

[0063] In some of these embodiments, such as Figure 3 As shown, step S210, which converts the input EVM bytecode sequence into the corresponding first intermediate representation, includes the following steps:

[0064] Step S211: Convert the input EVM bytecode sequence into the corresponding EVM intermediate representation; the EVM intermediate representation is a structured representation that preserves the stack-based operation semantics in the EVM bytecode sequence.

[0065] Step S212: Convert the EVM intermediate representation into the first intermediate representation.

[0066] In this embodiment, the EVM bytecode sequence is converted into a structured representation that preserves the stack-like operation semantics within the EVM bytecode sequence, namely, the EVM Intermediate Representation (IR). Specifically, based on the execution logic of the EVM bytecode sequence, the core operation semantics of the stack, such as push, pop, operation, and jump, are parsed and restored. At the same time, the triggering conditions and response logic for abnormal scenarios are covered to ensure semantic integrity. Finally, the stack-like semantics are expressed in a structured format using a standard structured format.

[0067] For example, the EVM bytecode sequence is PUSH1 0x01 PUSH1 0x02 ADD. Converting the EVM bytecode sequence to the corresponding EVM intermediate representation is as follows:

[0068] EVM IR:

[0069] v1 = push 1

[0070] v2 = push 2

[0071] v3 = add v1, v2

[0072] Furthermore, the stack operations and semantic constraints in the EVM intermediate representation are mapped to a generalized description form (such as the instruction format and data structure definition of LLVMIR), thereby converting the EVM intermediate representation into a first intermediate representation.

[0073] In this embodiment, the input EVM bytecode sequence is converted into the corresponding EVM intermediate representation. The EVM intermediate representation is a structured representation that preserves the stack-like operation semantics in the EVM bytecode sequence. The EVM intermediate representation is then converted into a first intermediate representation, thereby achieving a precise mapping of the EVM bytecode sequence to the intermediate representation layer. This process ensures the complete transmission of the core execution logic and semantics of the original bytecode sequence and provides a unified semantic description benchmark for subsequent semantic equivalence verification to support the comparison in the verification process.

[0074] In some embodiments, the step S212 of converting the EVM intermediate representation into a first intermediate representation includes the following steps:

[0075] Based on pre-built stack-based operation semantic mapping, execution state mapping, and instruction translation rules, the EVM intermediate representation is converted into a first intermediate representation;

[0076] Among them, the stack operation semantic mapping indicates the correspondence between the stack operations of the EVM intermediate representation and the register operations of the first intermediate representation; the execution state mapping indicates the correspondence between the execution context of the EVM intermediate representation and the data structure of the first intermediate representation; and the instruction translation rule indicates the correspondence between the operation instructions of the EVM intermediate representation and the operation instructions of the first intermediate representation.

[0077] Specifically, to achieve accurate conversion from the EVM intermediate representation to the first intermediate representation, the following core mapping rules and correspondences are pre-constructed:

[0078] 1. Construct a stack-based operation semantic mapping, which indicates the correspondence between stack operations in the EVM intermediate representation and register operations in the first intermediate representation. Taking the first intermediate representation using LLVM IR as an example, the operand stack of the EVM is simulated through LLVM local variables, and a corresponding LLVM virtual register is allocated for each stack position.

[0079] 2. Construct instruction translation rules, which indicate the correspondence between operation instructions in the EVM intermediate representation and operation instructions in the first intermediate representation. Taking LLVM IR as an example for the first intermediate representation, the instruction translation rules include: 1) Arithmetic instructions: EVM's ADD instruction → LLVM's add instruction; 2) Memory operations: EVM's MLOAD instruction → LLVM's load instruction; 3) Store operations: EVM's SSTORE instruction → LLVM's function call (simulating state storage); 4) Control flow: EVM's JUMP instruction → LLVM's br instruction.

[0080] 3. Construct an execution state mapping, which indicates the correspondence between the execution context of the EVM intermediate representation and the data structure of the first intermediate representation. Taking the first intermediate representation using LLVM IR as an example, the EVM execution context (including gas consumption, program counter, memory, etc.) is simulated through LLVM structures, and the execution state is passed through LLVM global variables or function parameters.

[0081] Subsequently, based on pre-built stack-based operation semantic mapping, execution state mapping, and instruction translation rules, the EVM intermediate representation is converted into a first intermediate representation. For example, consider the following EVM bytecode sequence:

[0082] PUSH1 0x0a; Push value 10

[0083] PUSH1 0x14; Push value 20

[0084] ADD; Performs addition operation

[0085] PUSH1 0x00; Push memory address 0

[0086] MSTORE; Store results

[0087] If the first intermediate representation uses LLVM IR, the first intermediate representation obtained by translating the above EVM bytecode sequence is as follows:

[0088] define i256 @evm_function() {

[0089] %1 = alloca i256

[0090] %2 = alloca i256

[0091]

[0092]

[0093]

[0094]

[0095] %5 = add i256 %3, %4

[0096] call void @memory_store(i256 0, i256 %5)

[0097] ret i256 %5

[0098] }

[0099] In this embodiment, based on the pre-built stack-based operation semantic mapping, execution state mapping, and instruction translation rules, the EVM intermediate representation is converted into a first intermediate representation, thereby realizing the conversion of the EVM intermediate representation into a generalized form. This provides a structurally consistent and semantically traceable comparison basis for subsequent semantic equivalence verification with the second intermediate representation corresponding to the target machine code sequence.

[0100] In some of these embodiments, such as Figure 4 As shown, step S230, converting the target machine code sequence into the corresponding second intermediate representation, includes the following steps:

[0101] Step S231: Perform binary enhancement processing on the target machine code sequence to obtain the corresponding second intermediate representation; the target machine code sequence is a binary machine code file, an executable file, or assembly code.

[0102] Specifically, after compiling and generating the target machine code sequence, tools such as the static binary translator Remill, the binary lifting framework McSema, or the machine code decompiler RetDec are used to perform binary lifting processing on the target machine code sequence to convert it into the corresponding second intermediate representation. The target machine code sequence can take the form of, but is not limited to, binary machine code files, executable files, and assembly code.

[0103] For example, the EVM bytecode sequence is input into the EVM AOT compiler to be verified, which compiles it into an x86-64 machine code sequence, and the x86-64 assembly instructions are translated into an equivalent second intermediate representation using a binary boosting tool. The second intermediate representation uses LLVM IR.

[0104] This embodiment performs binary enhancement processing on the target machine code sequence to obtain the corresponding second intermediate representation, thereby realizing the mapping of the target machine code sequence to a generalized intermediate representation layer and transforming the execution semantics of machine instructions into a general description. Simultaneously, it provides a unified general semantic benchmark for subsequent semantic equivalence verification with the first intermediate representation.

[0105] In some of these embodiments, such as Figure 5 As shown, step S240, which verifies the semantic equivalence of the first intermediate representation and the second intermediate representation, includes the following steps:

[0106] Step S241: The semantic equivalence of the first intermediate representation and the second intermediate representation is verified by a semantic verification tool based on the constraint solver.

[0107] Specifically, a semantic verification tool is used to verify the semantic equivalence of the first and second intermediate representations. This verifies whether the two code segments are equivalent in key semantic dimensions such as execution logic, input / output mapping, and memory / storage operations. It should be noted that the semantic verification tool used in this embodiment is compatible with the specific formats of the first and second intermediate representations, thus providing reliable tool support for determining their semantic equivalence.

[0108] For example, both the first and second intermediate representations are LLVM IR. The first intermediate representation is marked as the source function, and the second intermediate representation is marked as the target function. Subsequently, the semantic verification tool Alive2, based on the SMT solver, is invoked to traverse the execution paths of both functions through symbolic execution. Semantic constraints are constructed on key dimensions such as input-output mapping, memory / storage operation consistency, and execution logic branch coverage. Then, the constraint solving is used to determine whether the source function and the target function satisfy semantic equivalence.

[0109] In this embodiment, a semantic verification tool based on constraint solvers is used to verify the semantic equivalence of the first intermediate representation and the second intermediate representation, thereby accurately verifying whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0110] In some embodiments, the above-described blockchain virtual machine compiler translation verification method further includes the following steps:

[0111] When the verification result indicates that the semantic equivalence between the first intermediate representation and the second intermediate representation fails, a corresponding counterexample input is generated by the semantic verification tool; the counterexample input is the input value that proves that the first intermediate representation and the second intermediate representation are not semantically equivalent.

[0112] Specifically, when the verification result indicates that the first intermediate representation and the second intermediate representation are not equivalent, the semantic verification tool based on the constraint solver will automatically generate a counterexample input. This counterexample input is an input value that can trigger behavioral differences between the first intermediate representation and the second intermediate representation in dimensions such as execution logic, memory / storage operations, or input / output mapping.

[0113] Furthermore, based on the counterexample input from the constraint solver output, the EVM bytecode sequence and the target machine code sequence can be executed separately 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. Subsequently, the execution trajectories of the EVM bytecode sequence and the target machine code sequence are compared. By comparing the corresponding state changes instruction by instruction, the location of the instruction that first caused the behavioral difference is accurately pinpointed, 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 causing 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.

[0114] In this embodiment, when the verification result indicates that the semantic equivalence between the first intermediate representation and the second intermediate representation fails, a corresponding counterexample input is generated by the semantic verification tool to demonstrate the inconsistency between the source and target side outputs, which facilitates the rapid location of the instruction that causes the behavioral difference.

[0115] In some of these embodiments, the first intermediate representation and the second intermediate representation are LLVM intermediate representations.

[0116] Specifically, the input EVM bytecode sequence and the target machine code sequence compiled based on the EVM bytecode sequence are converted to obtain the LLVM intermediate representation of the EVM bytecode sequence (i.e., the first intermediate representation) and the LLVM intermediate representation of the target machine code sequence (i.e., the second intermediate representation).

[0117] For example, consider the following EVM bytecode sequence:

[0118] PUSH1 0x0a; Push value 10

[0119] PUSH1 0x14; Push value 20

[0120] ADD; Performs addition operation

[0121] PUSH1 0x00; Push memory address 0

[0122] MSTORE; Store results

[0123] The first intermediate representation uses LLVM IR, and the first intermediate representation obtained by translating the above EVM bytecode sequence is as follows:

[0124] define i256 @evm_function() {

[0125] %1 = alloca i256

[0126] %2 = alloca i256

[0127]

[0128]

[0129]

[0130]

[0131] %5 = add i256 %3, %4

[0132] call void @memory_store(i256 0, i256 %5)

[0133] ret i256 %5

[0134] }

[0135] Furthermore, the aforementioned EVM bytecode sequence is input into the EVM AOT compiler to be verified, which compiles it into an x86-64 machine code sequence. A binary elevation tool then translates the x86-64 assembly instructions into a second intermediate representation. This second intermediate representation uses LLVM IR, as detailed below:

[0136] define i256 @compiled_function() {

[0137] call void @memory_store(i256 0, i256 30)

[0138] ret i256 30

[0139] In this embodiment, both the first and second intermediate representations adopt LLVM intermediate representations, thereby unifying the semantic benchmark, eliminating cross-format heterogeneity, and helping to reduce the parsing complexity and comparison error of semantic equivalence verification. Simultaneously, the LLVM IR is adapted to a generalized verification framework design, significantly improving the solution's adaptability to different application scenarios and broadening its applicability.

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

[0141] Reference Figure 6As shown, the input EVM bytecode sequence is converted into a corresponding EVM intermediate representation. This intermediate representation is a structured representation that preserves the stack-based operation semantics of the EVM bytecode sequence. The intermediate representation is then translated into the source-side LLVM IR (i.e., the first intermediate representation). Furthermore, the EVM bytecode sequence is input into the EVM AOT compiler to be verified, which compiles it into an x86-64 machine code sequence. This x86-64 machine code sequence is then translated into the target-side LLVM IR (i.e., the second intermediate representation) using a binary enhancement tool.

[0142] The Alive2 verification engine performs semantic equivalence verification on the first and second intermediate representations to obtain the verification result. If the verification result indicates that the verification passed, it means that the EVM AOT compiler compiled correctly. Conversely, if the verification result indicates that the verification failed, it means that the EVM AOT compiler compiled incorrectly. At this point, the Alive2 verification engine generates a counterexample input. Based on the counterexample input output by the constraint solver, the EVM bytecode sequence and the target machine code sequence are executed respectively to obtain the corresponding execution trajectory. Then, the execution trajectory of the EVM bytecode sequence is compared with the execution trajectory of the target machine code sequence to accurately locate the instruction position where the behavior first differs, and the location information is recorded synchronously. Based on the location information, the corresponding error report is output.

[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 a blockchain virtual machine compiler. This device is used to implement the above embodiments and preferred embodiments, and 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 7 This is a structural block diagram of the translation and verification device of the blockchain virtual machine compiler in this embodiment, as shown below. Figure 7 As shown, the device includes:

[0146] The first conversion module 10 is used to convert the input EVM bytecode sequence into a corresponding first intermediate representation; the first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence.

[0147] Compilation module 20 is used to compile the EVM bytecode sequence into the target machine code sequence using the compiler to be verified;

[0148] The second conversion module 30 is used to convert the target machine code sequence into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence.

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

[0150] The apparatus provided in this embodiment converts the input EVM bytecode sequence into a corresponding first intermediate representation; the first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence; the EVM bytecode sequence is compiled into a target machine code sequence using a compiler to be verified; the target machine code sequence is converted into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence; semantic equivalence verification is performed on the first intermediate representation and the second intermediate representation to obtain the verification result, thus solving the problem of not being able to verify whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent, and realizing the verification of whether the compiled machine code sequence and the original EVM bytecode sequence are semantically equivalent.

[0151] In some embodiments, the first conversion module 10 is further configured to convert the input EVM bytecode sequence into a corresponding EVM intermediate representation; the EVM intermediate representation is a structured representation that preserves the stack-based operation semantics in the EVM bytecode sequence; and to convert the EVM intermediate representation into a first intermediate representation.

[0152] In some embodiments, the first conversion module 10 is further configured to convert the EVM intermediate representation into a first intermediate representation based on a pre-built stack-based operation semantic mapping, execution state mapping, and instruction translation rules; wherein the stack-based operation semantic mapping indicates the correspondence between stack operations of the EVM intermediate representation and register operations of the first intermediate representation; the execution state mapping indicates the correspondence between the execution context of the EVM intermediate representation and the data structure of the first intermediate representation; and the instruction translation rules indicate the correspondence between operation instructions of the EVM intermediate representation and operation instructions of the first intermediate representation.

[0153] In some embodiments, the second conversion module 30 is further configured to perform binary enhancement processing on the target machine code sequence to obtain a corresponding second intermediate representation; the target machine code sequence is a binary machine code file, an executable file, or assembly code.

[0154] In some embodiments, the verification module 40 is also configured to perform semantic equivalence verification on the first intermediate representation and the second intermediate representation using a semantic verification tool based on the constraint solver.

[0155] In some embodiments, the verification module 40 is further configured to generate a corresponding counterexample input through a semantic verification tool when the verification result indicates that the semantic equivalence between the first intermediate representation and the second intermediate representation fails; the counterexample input is an input value that proves that the first intermediate representation and the second intermediate representation are semantically inequivalent.

[0156] 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.

[0157] 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.

[0158] 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.

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

[0160] S1, convert the input EVM bytecode sequence into the corresponding first intermediate representation; the first intermediate representation is the general semantic mapping representation of the EVM bytecode sequence;

[0161] S2, using the compiler to be verified, compiles the EVM bytecode sequence into the target machine code sequence;

[0162] S3, convert the target machine code sequence into the corresponding second intermediate representation; the second intermediate representation is the general semantic mapping representation of the target machine code sequence;

[0163] S4. Perform semantic equivalence verification on the first intermediate representation and the second intermediate representation to obtain the verification result.

[0164] 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.

[0165] Furthermore, in conjunction with the blockchain virtual machine compiler translation verification method 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 of the blockchain virtual machine compiler translation verification methods described in the above embodiments.

[0166] 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.

[0167] 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.

[0168] 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.

[0169] 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 a blockchain virtual machine compiler, characterized in that, include: Convert the input EVM bytecode sequence into the corresponding first intermediate representation; The first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence; The EVM bytecode sequence is compiled into a target machine code sequence using the compiler to be verified. The target machine code sequence is converted into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence. Semantic equivalence verification is performed on the first intermediate representation and the second intermediate representation to obtain the verification result.

2. The translation verification method for the blockchain virtual machine compiler according to claim 1, characterized in that, The step of converting the input EVM bytecode sequence into the corresponding first intermediate representation includes: The input EVM bytecode sequence is converted into a corresponding EVM intermediate representation; the EVM intermediate representation is a structured representation that preserves the stack-based operation semantics in the EVM bytecode sequence. Convert the EVM intermediate representation into the first intermediate representation.

3. The translation verification method for the blockchain virtual machine compiler according to claim 2, characterized in that, The step of converting the EVM intermediate representation into the first intermediate representation includes: Based on pre-built stack-based operation semantic mapping, execution state mapping, and instruction translation rules, the EVM intermediate representation is converted into the first intermediate representation; Wherein, the stack-based operation semantic mapping indicates the correspondence between the stack operations of the EVM intermediate representation and the register operations of the first intermediate representation; the execution state mapping indicates the correspondence between the execution context of the EVM intermediate representation and the data structure of the first intermediate representation; and the instruction translation rule indicates the correspondence between the operation instructions of the EVM intermediate representation and the operation instructions of the first intermediate representation.

4. The translation verification method for the blockchain virtual machine compiler according to claim 1, characterized in that, The step of converting the target machine code sequence into a corresponding second intermediate representation includes: The target machine code sequence is subjected to binary enhancement processing to obtain the corresponding second intermediate representation; the target machine code sequence is a binary machine code file, an executable file, or assembly code.

5. The translation verification method for the blockchain virtual machine compiler according to claim 1, characterized in that, The semantic equivalence verification of the first intermediate representation and the second intermediate representation includes: The semantic equivalence of the first intermediate representation and the second intermediate representation is verified using a semantic verification tool based on constraint solvers.

6. The translation verification method for the blockchain virtual machine compiler according to claim 1 or 5, characterized in that, The method further includes: When the verification result indicates that the semantic equivalence between the first intermediate representation and the second intermediate representation fails, the semantic verification tool generates a corresponding counterexample input; the counterexample input is an input value that proves that the first intermediate representation and the second intermediate representation are semantically inequivalent.

7. The translation verification method for a blockchain virtual machine compiler according to any one of claims 1 to 6, characterized in that, The first intermediate representation and the second intermediate representation are LLVM intermediate representations.

8. A translation verification device for a blockchain virtual machine compiler, characterized in that, include: The first conversion module is used to convert the input EVM bytecode sequence into the corresponding first intermediate representation; The first intermediate representation is a general semantic mapping representation of the EVM bytecode sequence; A compilation module is used to compile the EVM bytecode sequence into a target machine code sequence using a compiler to be verified. The second conversion module is used to convert the target machine code sequence into a corresponding second intermediate representation; the second intermediate representation is a general semantic mapping representation of the target machine code sequence. The verification module is used to perform semantic equivalence verification on the first intermediate representation and the second intermediate representation 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 blockchain virtual machine 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 a processor, it implements the steps of the translation and verification method of the blockchain virtual machine compiler as described in any one of claims 1 to 7.

Images