Theoretical prover-based EVM (Error Vector Magnitude) implementation layer semantic description method and device

Abstract

The invention relates to the technical field of block chains, and provides an EVM (Error Vector Magnitude) implementation layer semantic description method and device based on a theorem prover, electronic equipment and a computer program product. The method comprises the following steps: acquiring an EVM execution engine code to be processed; the method comprises the following steps: respectively converting execution logic of each EVM instruction of an EVM execution engine code into corresponding realization layer semantic description based on a theorem prover according to predefined data structures and instruction behaviors of various EVM instructions; according to the method, high-fidelity formalized modeling is performed on an implementation layer of an EVM execution engine code in a high-credibility theorem prover according to defined data structures and instruction behaviors of various EVM instructions, so that high-accuracy semantic description of the implementation layer can be obtained.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a semantic description method, apparatus, electronic device and computer program product for EVM implementation layer based on theorem prover. Background Technology

[0002] In the field of blockchain technology, the Ethereum Virtual Machine (EVM), as the underlying execution environment for smart contracts, directly impacts the trustworthiness of the blockchain system through the correctness and security of its implementation layer semantic description. Therefore, how to formally model the EVM implementation layer to obtain a highly accurate semantic description of it becomes a technical problem that those skilled in the art need to consider. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method, apparatus, electronic device, and computer program product for semantic description of EVM implementation layer based on theorem prover, which can perform formal modeling of EVM implementation layer and obtain highly accurate semantic description of implementation layer.

[0004] The first aspect of this application provides a semantic description method for the EVM implementation layer based on a theorem prover, including:

[0005] Obtain the EVM execution engine code to be processed;

[0006] Based on the predefined data structures and instruction behaviors of various EVM instructions, and using the theorem prover, the execution logic of each EVM instruction in the EVM execution engine code is converted into a corresponding implementation layer semantic description.

[0007] The technical solution of this application, after obtaining the EVM execution engine code to be processed, converts the execution logic of each EVM instruction in the EVM execution engine code into a corresponding implementation layer semantic description based on the predefined data structures and instruction behaviors of various EVM instructions and a theorem prover. This process, based on the predefined data structures and instruction behaviors of various EVM instructions, performs high-fidelity formal modeling of the implementation layer of the EVM execution engine code in a high-confidence theorem prover, thereby obtaining a highly accurate implementation layer semantic description.

[0008] In one implementation of this application, the EVM implementation layer semantic description method based on theorem provers further includes:

[0009] During the execution of the EVM execution engine code, the complete execution semantics of the EVM execution engine code are determined based on the implementation layer semantic description corresponding to the execution logic of each EVM instruction in the EVM execution engine code.

[0010] In one implementation of this application, based on the predefined data structures and instruction behaviors of various EVM instructions, and using a theorem prover, the execution logic of each EVM instruction in the EVM execution engine code is converted into a corresponding implementation-level semantic description, including:

[0011] For any EVM instruction in the EVM execution engine code, the execution logic of any EVM instruction is converted into a corresponding implementation layer semantic description in the theorem prover through formal object expression. The implementation layer semantic description corresponding to the execution logic of any EVM instruction includes new state information, exception information, and resource consumption information corresponding to any EVM instruction during execution, determined according to the data structure and instruction behavior.

[0012] In one implementation of this application, the EVM implementation layer semantic description method based on theorem provers further includes:

[0013] During the execution of the EVM execution engine code, a state transition information chain is constructed based on the state changes described in the implementation layer semantics of each EVM instruction; an exception information chain is constructed based on the exception information described in the implementation layer semantics of each EVM instruction; and a resource consumption information chain is constructed based on the resource consumption information described in the implementation layer semantics of each EVM instruction.

[0014] In one implementation of this application, the EVM implementation layer semantic description method based on theorem provers further includes:

[0015] Using the theorem prover, we infer all state transition paths, all exception paths, and all resource consumption paths that exist in the EVM execution engine code.

[0016] The EVM execution engine code is automatically verified based on the state transition information chain, all state transition paths, exception information chain, all exception paths, resource consumption information chain, and all resource consumption paths.

[0017] In one implementation of this application, the EVM execution engine code is automatically verified based on the state transition information chain, all state transition paths, exception information chain, all exception paths, resource consumption information chain, and all resource consumption paths, including:

[0018] Using the automated proof engine of the theorem prover, the correctness of the state transitions of the EVM execution engine code is verified based on the state transition information chain and all state transition paths; the completeness of exception coverage of the EVM execution engine code is verified based on the exception information chain and all exception paths; and the resource consumption of the code execution is verified based on the resource consumption information chain and all resource consumption paths.

[0019] In one implementation of this application, the EVM implementation layer semantic description method based on theorem provers further includes:

[0020] The formal model that performs the transformation is converted into executable code through the code extraction mechanism of the theorem prover.

[0021] A second aspect of this application provides an EVM implementation layer semantic description apparatus based on a theorem prover, comprising:

[0022] The EVM execution engine code acquisition module is used to acquire the EVM execution engine code to be processed.

[0023] The implementation layer semantic description module is used to convert the execution logic of each EVM instruction in the EVM execution engine code into a corresponding implementation layer semantic description based on the predefined data structure and instruction behavior of various EVM instructions and the theorem prover.

[0024] A third aspect of this application provides an electronic 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 EVM implementation layer semantic description method based on theorem provers provided in the first aspect of this application.

[0025] A fourth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the EVM implementation layer semantic description method based on theorem provers provided in the first aspect of this application.

[0026] A fifth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the EVM implementation layer semantic description method based on a theorem prover provided in the first aspect of this application.

[0027] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0029] Figure 1This is a flowchart of a semantic description method for an EVM implementation layer based on a theorem prover, provided in an embodiment of this application.

[0030] Figure 2 This is a schematic diagram of the overall technical framework adopted by the EVM implementation layer semantic description method based on theorem prover provided in the embodiments of this application;

[0031] Figure 3 This is a schematic diagram of the structure of an EVM implementation layer semantic description device based on a theorem prover provided in an embodiment of this application;

[0032] Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail. Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0034] As the underlying execution environment for smart contracts, the correctness and security of the semantic description of the Ethereum Virtual Machine (EVM) implementation layer directly impact the trustworthiness of the blockchain system. When executing smart contracts, a compiler typically translates the smart contract program into the underlying EVM execution engine code, and then an interpreter or other execution engine interprets and executes the EVM instructions line by line. Therefore, formal modeling of the EVM execution engine code implementation layer to obtain a highly accurate semantic description is crucial. Currently, the mainstream EVM engineering implementation method is commonly used for formal modeling of the EVM implementation layer. This method implements the EVM interpreter using engineering code, making it difficult to formally verify the consistency of instruction behavior with the specification, and lacks verifiable modeling of details such as exception handling and resource consumption.

[0035] To address the aforementioned technical problems in existing technologies, this application provides a method, apparatus, electronic device, and computer program product for semantic description of the EVM implementation layer based on a theorem prover. By performing high-fidelity formal modeling of the EVM execution engine code implementation layer in a high-confidence theorem prover, it can accurately reproduce the data structures and instruction execution flows of mainstream EVM implementations, model exception handling and resource consumption with fine granularity, and support automated verification and high-confidence code generation, thereby improving the formal verification capability and security level of the EVM implementation. For more specific technical implementation details of the embodiments of this application, please refer to the various method embodiments described below.

[0036] It should be understood that the implementing entity of the various method embodiments proposed in this application can be various types of electronic devices, such as mobile phones, tablets, desktop computers, wearable devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), large-screen TVs, etc. This application does not impose any limitation on the specific type of electronic device. For example, if applied in a blockchain technology scenario, the electronic device can be any blockchain node.

[0037] Please see Figure 1 This application illustrates an EVM implementation layer semantic description method based on a theorem prover, comprising:

[0038] 101. Obtain the EVM execution engine code to be processed;

[0039] First, the EVM execution engine code to be processed is obtained. This code may contain multiple EVM instructions of different types. Subsequent operations require converting the execution logic of each EVM instruction into a corresponding implementation-level semantic description to complete the high-fidelity formal modeling of the implementation layer of the EVM execution engine code. Implementation-level semantics describes the behavioral characteristics of the system in actual engineering implementation and focuses more on implementation details than abstract semantics.

[0040] 102. Based on the predefined data structures and instruction behaviors of various EVM instructions, and using the theorem prover, convert the execution logic of each EVM instruction in the EVM execution engine code into a corresponding implementation layer semantic description.

[0041] The technical solutions of this application predefine the data structures and instruction behaviors of various EVM instructions. The data structures may include, but are not limited to, stack structures, memory-mapped structures, storage-mapped structures, account structures, block structures, transaction structures, and environment context structures. Instruction behaviors describe the execution actions of the corresponding EVM instructions, such as state transitions, possible exceptions, and resource consumption. In practice, data structures (including segmented stacks, memory mappings, account / block / environment contexts, etc.) completely consistent with mainstream EVM engineering implementations (e.g., the go-ethereum client) can be defined. This not only aligns with mainstream EVM engineering implementations in form but also ensures the security and consistency of the data structures at the type system level, laying the foundation for subsequent automated verification and code generation.

[0042] After obtaining the EVM execution engine code to be processed, a high-confidence theorem prover is introduced. In the theorem prover, the execution logic of each EVM instruction in the EVM execution engine code is converted into a corresponding implementation-level semantic description. By utilizing the high-confidence theorem prover, the instruction behavior during EVM instruction execution can be described mathematically accurately and completely, thereby improving the accuracy of the implementation-level semantic description of the EVM execution engine code. The theorem prover used here can be of, but is not limited to, the following types: Isabelle / HOL, Coq, and Lean, etc., as long as the theorem prover has the function of formal object expression.

[0043] In practice, formal semantic techniques can be used to complete the modeling, constructing a formal model for implementing the semantic transformation of the implementation layer. Based on the data structure and instruction behavior defined above, this formal model is expressed in the theorem prover using formal objects such as record and datatype, converting the execution logic of EVM instructions into corresponding implementation-layer semantic descriptions. This ensures that the model transformation results are consistent with real industrial implementations.

[0044] As an example, Figure 2 This is a schematic diagram of the overall technical framework used in the EVM implementation layer semantic description method based on theorem prover provided in the embodiments of this application. Figure 2 The technical framework shown consists of four parts: data structure and state modeling that are highly consistent with the actual EVM implementation, fine-grained exception handling and resource consumption modeling, instruction execution semantics and interpreter modeling, and automated verification and code generation support.

[0045] Among them, data structure and state modeling that are highly consistent with the actual EVM implementation: mainly define data structures and states that are completely consistent with the mainstream EVM engineering implementation. For example, use the u256 list data type to describe the stack structure, use the function mapping type u256 => byte to describe the memory mapping, use the function mapping type u256 => u256 to describe the storage mapping, and define the data structures of accounts, blocks and transactions according to the data structures of the mainstream EVM engineering implementation.

[0046] Fine-grained exception handling and resource consumption modeling: It achieves full coverage of exceptions by enumerating all possible exceptions for EVM instructions (such as stack overflow, memory overflow, insufficient gas, illegal jumps, and invalid opcodes) as independent types. A formal model is used to perform condition checks before and after the execution of each EVM instruction, returning exceptions as part of the state transition result. It also enables precise modeling of resource consumption, mathematically modeling the gas consumption, memory expansion, and storage operations of each EVM instruction, considering both static consumption and dynamic calculations of additional costs such as memory expansion and storage writes. Furthermore, it allows for parallel tracking of exceptions and resource consumption. For each state transition of an EVM instruction, it simultaneously outputs new state information, exception information, and resource consumption information, automatically tracing exception and resource consumption information chains for subsequent automated verification and security analysis.

[0047] Instruction execution semantics and interpreter modeling: A layered semantic modeling approach is adopted, dividing the execution semantics of EVM instructions into "instruction-level semantics" (input / output, state transitions, exceptions, and resource consumption of a single instruction) and "interpreter-level semantics" (recursive execution of the instruction flow, termination conditions, and environment interactions). These two layers are decoupled, facilitating individual verification and combinatorial reasoning. Combinatorial state transitions are implemented; the execution semantics of each EVM instruction not only describe state changes but also explicitly address the impact of exceptions and resource consumption. The semantics of all EVM instructions can be automatically combined into the program execution semantics of the complete EVM execution engine code. An exception-priority and fuel-decreasing mechanism is introduced; the interpreter's main loop employs a "fuel-decreasing + exception-priority" mechanism, ensuring that each step can be formally reasoned and resource-measured. When an exception is encountered, the loop immediately interrupts and returns the exception information chain. It features alignment with actual EVM implementations; the execution flow, boundary conditions, exception handling, and resource consumption of all EVM instructions are consistent with mainstream EVM implementations, facilitating comparison and verification.

[0048] Automated verification and code generation support: Automated verification is supported, utilizing the automated proof engine of theorem provers such as Isabelle / HOL to automatically verify the performance of formal models, including type safety, anomaly coverage, resource consumption limits, and state transition correctness. Proof scripts can be automatically generated to verify the robustness and consistency of the model. Full coverage checks of anomaly and resource consumption chains are supported. By introducing a "verifiable anomaly and resource consumption information chain" mechanism, all possible anomaly paths and resource consumption paths can be automatically checked without omission. Executable code generation is supported. Utilizing the code extraction mechanism of theorem provers such as Isabelle / HOL, formal models can be automatically converted into highly reliable executable code, ensuring consistency between the implementation and the model. Integration with official test sets is supported. Formal models can be integrated with the official EVM test set, automatically comparing the output of the formal model with the behavior of the actual EVM implementation, further improving the credibility of semantic transformation at the implementation layer.

[0049] use Figure 2 The technical framework shown can accurately reproduce the data structures and instruction execution flow of mainstream EVM implementations, provide fine-grained modeling of exception handling and resource consumption, and support automated verification and high-confidence code generation, facilitating comparison and verification with the original code. About Figure 2 For details on the specific technical implementation of the framework shown, please refer to the following text.

[0050] In one implementation of this application, based on the predefined data structures and instruction behaviors of various EVM instructions, and using a theorem prover, the execution logic of each EVM instruction in the EVM execution engine code is converted into a corresponding implementation-level semantic description, including:

[0051] For any EVM instruction in the EVM execution engine code, the execution logic of any EVM instruction is converted into a corresponding implementation layer semantic description in the theorem prover through formal object expression. The implementation layer semantic description corresponding to the execution logic of any EVM instruction includes new state information, exception information, and resource consumption information corresponding to any EVM instruction during execution, determined according to the data structure and instruction behavior.

[0052] When performing the implementation-level semantic transformation of the EVM execution engine code, each EVM instruction can be read sequentially. Following the data structure and instruction behavior defined above, and using formal objects such as `record` and `datatype` in the theorem provers like Isabelle / HOL, the execution logic of each EVM instruction is converted into a corresponding implementation-level semantic description. The implementation-level semantic description corresponding to the execution logic of each EVM instruction includes new state information, exception information, and resource consumption information determined according to the aforementioned data structure and instruction behavior. New state information may include stack state, memory state, storage state, jump state, and Gas state; exception information may include stack overflow, OutOfGas, and illegal jumps; and resource consumption information may include the amount of Gas consumed in this step and memory expansion. In summary, the implementation-level semantics of each EVM instruction is a structured object containing information such as input state, output state, possible exceptions, and resource consumption. For example, the implementation semantics of the ADD instruction not only describe "adding the two numbers at the top of the stack", but also describe information such as throwing an exception if the stack depth is insufficient, how much gas is consumed, and the new stack state.

[0053] In one implementation of this application, the EVM implementation layer semantic description method based on theorem provers further includes:

[0054] During the execution of the EVM execution engine code, a state transition information chain is constructed based on the state changes described in the implementation layer semantics of each EVM instruction; an exception information chain is constructed based on the exception information described in the implementation layer semantics of each EVM instruction; and a resource consumption information chain is constructed based on the resource consumption information described in the implementation layer semantics of each EVM instruction.

[0055] Traditional EVM semantic models typically model state transitions, exception handling, and resource consumption separately from the EVM execution engine code, making formal verification and automated reasoning difficult. This application introduces a mechanism for parallel tracking of exceptions and resource consumption. During each state transition, the "new state information - exception information - resource consumption information" are treated as an inseparable whole output and recursively combined in the interpreter's main loop to form a complete "state transition information chain - exception information chain - resource consumption information chain." This setup allows the theorem prover to automatically enumerate and verify all possible exception paths and resource consumption paths, automatically detect missed exception handling or resource consumption anomalies, and directly generate code consistent with the actual EVM implementation, ensuring that exception and resource consumption logic are not omitted or tampered with. During the execution of the EVM execution engine code, each recursion uses the output of the previous step as the input of the next step until a termination condition is encountered (e.g., an exception occurs, fuel is exhausted, etc.). Upon termination, the complete state transition information chain, exception information chain, and resource consumption information chain are output.

[0056] Specifically, based on the state changes described in the implementation layer semantics of each EVM instruction in the EVM execution engine code, the jump states of each EVM instruction can be obtained sequentially. Combining these jump states generates a state transition information chain. Based on the exception information described in the implementation layer semantics of each EVM instruction, various possible exceptions for each EVM instruction can be obtained sequentially. Combining these exceptions generates an exception information chain. Based on the resource consumption information described in the implementation layer semantics of each EVM instruction, the corresponding resource consumption for each EVM instruction can be obtained sequentially. Combining these resource consumption information generates a resource consumption information chain. In summary, these three types of information are recursively combined in the interpreter's main loop, forming a complete and traceable information chain covering all state transitions, exception occurrences, and resource consumption processes from the start to the end of the EVM execution engine code.

[0057] In one implementation of this application, the EVM implementation layer semantic description method based on theorem provers further includes:

[0058] During the execution of the EVM execution engine code, the complete execution semantics of the EVM execution engine code are determined based on the implementation layer semantic description corresponding to the execution logic of each EVM instruction in the EVM execution engine code.

[0059] During the execution of the EVM execution engine code, the implementation-level semantics of all EVM instructions can be automatically combined into complete program execution semantics. Specifically, upon obtaining the implementation-level semantic descriptions corresponding to the execution logic of each EVM instruction in the EVM execution engine code, these implementation-level semantic descriptions are combined sequentially to generate the complete execution semantics of the EVM execution engine code. All implementation-level semantics corresponding to all EVM instructions can adhere to a unified interface such as triples, which facilitates the combination of multiple implementation-level semantic descriptions into longer execution sequences. The interpreter's main loop recursively combines the implementation-level semantic descriptions corresponding to each EVM instruction to form the complete program execution path of the EVM execution engine code.

[0060] In one implementation of this application, the EVM implementation layer semantic description method based on theorem provers further includes:

[0061] (1) Using the theorem prover, infer all state transition paths, all exception paths, and all resource consumption paths that exist in the EVM execution engine code;

[0062] (2) Automatically verify the EVM execution engine code based on the state transition information chain, all state transition paths, exception information chain, all exception paths, resource consumption information chain, and all resource consumption paths.

[0063] Since the implementation-level semantics of all EVM instructions can be combined, the theorem prover can automatically infer the instruction behavior of the entire EVM execution engine code, including all state transition paths, all exception paths, and all resource consumption paths. Using the inferred state transition paths, exception paths, and resource consumption paths, combined with the aforementioned state transition information chains, exception information chains, and resource consumption information chains, automated verification of the EVM execution engine code can be achieved. Automated verification can cover aspects such as type safety, exception coverage, resource consumption limits, and state transition correctness of the formal model. By automatically generating proof text, the robustness and consistency of the model can be verified.

[0064] In one implementation of this application, the EVM execution engine code is automatically verified based on the state transition information chain, all state transition paths, exception information chain, all exception paths, resource consumption information chain, and all resource consumption paths, including:

[0065] Using the automated proof engine of the theorem prover, the correctness of the state transitions of the EVM execution engine code is verified based on the state transition information chain and all state transition paths; the completeness of exception coverage of the EVM execution engine code is verified based on the exception information chain and all exception paths; and the resource consumption of the code execution is verified based on the resource consumption information chain and all resource consumption paths.

[0066] Referring to the above description, in the formal modeling of the EVM implementation layer, each instruction execution explicitly outputs new state information, exception information, and resource consumption information. These three types of information are recursively combined in the interpreter's main loop to form a complete and traceable chain of state transition information, exception information, and resource consumption information. The execution result of each EVM instruction is a triple containing the new state, exception, and resource consumption. For example, executing an MSTORE instruction outputs the new memory state, whether an OutOfGas or memory out-of-bounds exception occurred, and the Gas value consumed in this operation. During each recursive step, the interpreter's main loop merges the exception and resource consumption from the previous step with the result of the current step. If an exception occurs at a certain step, subsequent steps will be immediately interrupted, and the exception information chain will completely record the path and cause of the exception. Because the exception and resource consumption at each step are structured and explicitly recorded, automated verification can be easily accomplished using the automated proof engine of theorem provers such as Isabelle / HOL. The specific verification process includes: verifying the correctness of state transitions in the EVM execution engine code based on the state transition information chain and all state transition paths; verifying the completeness of exception coverage in the EVM execution engine code based on the exception information chain and all exception paths, i.e., whether all possible exception paths are covered without omission; and verifying whether the resource consumption of the code execution exceeds the limit based on the resource consumption information chain and all resource consumption paths, such as ensuring that the Gas value is not negative, and also verifying whether certain safety attributes (such as no unhandled exceptions will occur) are valid.

[0067] In one implementation of this application, the EVM implementation layer semantic description method based on theorem provers further includes:

[0068] The formal model that performs the transformation is converted into executable code through the code extraction mechanism of the theorem prover.

[0069] This application's embodiments introduce a mechanism for parallel tracking of anomalies and resource consumption, facilitating the use of automated tools such as static analyzers and formal verifiers to perform full-coverage analysis of all execution paths in the EVM execution engine code, automatically identifying issues such as missed anomalies in anomaly handling and abnormal resource consumption. Furthermore, the code extraction mechanism of theorem provers such as Isabelle / HOL can transform the aforementioned formal model, which implements semantic transformation, into highly reliable executable code, such as Golang or OCaml, thereby ensuring consistency between the implementation and the model. Moreover, the aforementioned formal model can be integrated with the official EVM test set to automatically compare the behavioral differences between the model output and the actual EVM implementation, further enhancing credibility.

[0070] The technical solution of this application, after obtaining the EVM execution engine code to be processed, converts the execution logic of each EVM instruction in the EVM execution engine code into a corresponding implementation layer semantic description based on the predefined data structures and instruction behaviors of various EVM instructions and a theorem prover. This process, based on the predefined data structures and instruction behaviors of various EVM instructions, performs high-fidelity formal modeling of the implementation layer of the EVM execution engine code in a high-confidence theorem prover, thereby obtaining a highly accurate implementation layer semantic description.

[0071] In summary, this application proposes a method for high-fidelity formal modeling of EVM implementation layer semantics in a theorem prover. Its data structure, instruction flow, and state transitions are fully aligned with mainstream EVM implementations, facilitating comparison and verification of implementation correctness. Furthermore, by introducing a parallel tracking mechanism for exceptions and resource consumption, the exception and resource consumption of each EVM instruction are accurately modeled, supporting automated verification, security analysis, and high-confidence code generation.

[0072] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0073] The above mainly describes a semantic description method for the EVM implementation layer based on a theorem prover. The following will describe a semantic description device for the EVM implementation layer based on a theorem prover.

[0074] Please see Figure 3 This application illustrates an EVM implementation layer semantic description device based on a theorem prover, comprising:

[0075] EVM execution engine code acquisition module 301 is used to acquire the EVM execution engine code to be processed;

[0076] The implementation layer semantic description module 302 is used to convert the execution logic of each EVM instruction in the EVM execution engine code into a corresponding implementation layer semantic description based on the predefined data structure and instruction behavior of various EVM instructions and the theorem prover.

[0077] In one implementation of this application, the EVM implementation layer semantic description device based on the theorem prover further includes:

[0078] The complete semantic determination module is used to determine the complete execution semantics of the EVM execution engine code during the execution of the EVM execution engine code, based on the implementation layer semantic description corresponding to the execution logic of each EVM instruction in the EVM execution engine code.

[0079] In one implementation of this application, the semantic description module of the implementation layer includes:

[0080] The implementation layer semantic description unit is used to convert the execution logic of any EVM instruction in the EVM execution engine code into a corresponding implementation layer semantic description through formal object expression in the theorem prover. The implementation layer semantic description corresponding to the execution logic of any EVM instruction includes new state information, exception information, and resource consumption information corresponding to any EVM instruction during execution, which are determined according to the data structure and instruction behavior.

[0081] In one implementation of this application, the EVM implementation layer semantic description device based on the theorem prover further includes:

[0082] The information chain determination module is used to construct a state transition information chain based on the state changes described in the implementation layer semantics of each EVM instruction during the execution of the EVM execution engine code; to construct an exception information chain based on the exception information described in the implementation layer semantics of each EVM instruction; and to construct a resource consumption information chain based on the resource consumption information described in the implementation layer semantics of each EVM instruction.

[0083] In one implementation of this application, the EVM implementation layer semantic description device based on the theorem prover further includes:

[0084] The path inference module is used to infer all state transition paths, all exception paths, and all resource consumption paths existing in the EVM execution engine code through the theorem prover.

[0085] The automated verification module is used to automatically verify the EVM execution engine code based on the state transition information chain, all state transition paths, exception information chain, all exception paths, resource consumption information chain, and all resource consumption paths.

[0086] In one implementation of this application, the automated verification module includes:

[0087] The automated verification unit is used to verify the correctness of state transitions in the EVM execution engine code based on the state transition information chain and all state transition paths using the automated proof engine of the theorem prover; to verify the completeness of exception coverage in the EVM execution engine code based on the exception information chain and all exception paths; and to verify whether the resource consumption of the code execution exceeds the limit based on the resource consumption information chain and all resource consumption paths.

[0088] In one implementation of this application, the EVM implementation layer semantic description device based on the theorem prover further includes:

[0089] The model transformation module is used to convert the formal model into executable code through the code extraction mechanism of the theorem prover.

[0090] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the EVM implementation layer semantic description method based on theorem provers described in any of the above embodiments.

[0091] This application also provides a computer program product that, when run on an electronic device, causes the electronic device to execute the EVM implementation layer semantic description method based on theorem provers as described in any of the above embodiments.

[0092] Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 4 of this embodiment includes: a processor 40, a memory 41, and a computer program 42 stored in the memory 41 and executable on the processor 40. When the processor 40 executes the computer program 42, it implements the steps in the embodiments of the various EVM implementation layer semantic description methods based on theorem provers described above, for example... Figure 1 Steps 101-102 are shown. Alternatively, when the processor 40 executes the computer program 42, it implements the functions of each module / unit in the above-described device embodiments, for example, implementing... Figure 3 The functions of modules 301-302 of the device shown.

[0093] The computer program 42 can be divided into one or more modules / units, which are stored in the memory 41 and executed by the processor 40 to complete this application. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 42 in the electronic device 4.

[0094] The processor 40 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0095] The memory 41 can be an internal storage unit of the electronic device 4, such as a hard disk or memory. The memory 41 can also be an external storage device of the electronic device 4, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 41 can include both internal and external storage units of the electronic device 4. The memory 41 is used to store the computer program and other programs and data required by the electronic device. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0096] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0097] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0098] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0099] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

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

[0103] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

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

Claims

1. A semantic description method for the EVM implementation layer based on a theorem prover, characterized in that, include: Obtain the EVM execution engine code to be processed; Based on the predefined data structures and instruction behaviors of various EVM instructions, and using the theorem prover, the execution logic of each EVM instruction in the EVM execution engine code is converted into a corresponding implementation layer semantic description.

2. The method as described in claim 1, characterized in that, Also includes: During the execution of the EVM execution engine code, the complete execution semantics of the EVM execution engine code are determined based on the implementation layer semantic description corresponding to the execution logic of each EVM instruction in the EVM execution engine code.

3. The method as described in claim 1, characterized in that, The process of converting the execution logic of each EVM instruction in the EVM execution engine code into a corresponding implementation-level semantic description based on the predefined data structures and instruction behaviors of various EVM instructions and using a theorem prover includes: For any EVM instruction in the EVM execution engine code, the execution logic of any EVM instruction is converted into a corresponding implementation layer semantic description in the theorem prover through formal object expression; wherein, the implementation layer semantic description corresponding to the execution logic of any EVM instruction includes new state information, exception information and resource consumption information corresponding to any EVM instruction during execution, determined according to the data structure and the instruction behavior.

4. The method as described in claim 3, characterized in that, Also includes: During the execution of the EVM execution engine code, a state transition information chain is constructed based on the state changes described in the implementation layer semantics of each EVM instruction; Based on the exception information described in the implementation layer semantics of each EVM instruction, construct an exception information chain; based on the resource consumption information described in the implementation layer semantics of each EVM instruction, construct a resource consumption information chain.

5. The method as described in claim 4, characterized in that, Also includes: Using the theorem prover, infer all state transition paths, all exception paths, and all resource consumption paths existing in the EVM execution engine code; The EVM execution engine code is automatically verified based on the state transition information chain, all state transition paths, the exception information chain, all exception paths, the resource consumption information chain, and all resource consumption paths.

6. The method as described in claim 5, characterized in that, The automated verification of the EVM execution engine code based on the state transition information chain, all state transition paths, the exception information chain, all exception paths, the resource consumption information chain, and all resource consumption paths includes: Using the automated proof engine of the theorem prover, the correctness of the state transitions of the EVM execution engine code is verified based on the state transition information chain and all state transition paths; the completeness of exception coverage of the EVM execution engine code is verified based on the exception information chain and all exception paths; and the resource consumption of the code execution is verified based on the resource consumption information chain and all resource consumption paths to determine whether the resource consumption exceeds the limit.

7. The method according to any one of claims 1 to 6, characterized in that, Also includes: The formal model that implements the transformation is converted into executable code through the code extraction mechanism of the theorem prover.

8. A semantic description device for EVM implementation layer based on a theorem prover, characterized in that, include: The EVM execution engine code acquisition module is used to acquire the EVM execution engine code to be processed. The implementation layer semantic description module is used to convert the execution logic of each EVM instruction in the EVM execution engine code into a corresponding implementation layer semantic description based on the predefined data structure and instruction behavior of various EVM instructions and the theorem prover.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the EVM implementation layer semantic description method based on theorem prover as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, When the computer program product is run on an electronic device, the electronic device performs the EVM implementation layer semantic description method based on theorem prover as described in any one of claims 1 to 7.

Images