CN117688564B - A detection method, device and storage medium for smart contract event log - Google Patents

Abstract

The application relates to the technical field of computers, and discloses a detection method, a device and a storage medium for an intelligent contract event log, wherein the method comprises the following steps: acquiring a target contract; compiling a target contract by adopting Solidity language; analyzing Solidity codes of the target contracts, and determining event problem states of Solidity codes; the event problem state comprises at least one of the event in Solidity code that requires an optimization variable, the event in Solidity code that uses more frequently than a frequency of use threshold, the event in Solidity code that has parameter information errors, the redundant event in Solidity code, the debug event in Solidity code that has been used, and the event in Solidity code that has call position errors; based on the event problem state, outputting reminding information. Thus, the developer can find the problem of the event in time.

Description

A detection method, device and storage medium for smart contract event log

Technical Field

The present application relates to the field of computer technology, and in particular to a detection method, device and storage medium for smart contract event logs.

Background technique

Smart contracts are Turing-complete programs that run in the Ethereum Virtual Machine (EVM) in the form of EVM bytecode. Specifically, smart contracts can be programmed in Solidity (a programming language), which is first compiled into EVM bytecode and then executed on the blockchain by EVM.

Furthermore, in the Solidity programming process, logs can be recorded through the event function. However, there are problems with the use of events in the current Solidity code. If developers do not avoid them in time, it will lead to a waste of gas fees (a cost that needs to be paid when performing specific operations on the Ethereum blockchain), and even increase the risk of property loss of the contract account.

In the process of implementing the embodiments of the present disclosure, it is found that there are at least the following problems in the related art:

There are problems with the use of events in the current Solidity code. If developers do not avoid them in time, it will lead to a waste of gas fees and even increase the risk of property loss of the contract account.

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

Summary of the invention

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

The disclosed embodiments provide a detection method, device, and storage medium for smart contract event logs to detect problems with events in the current Solidity code when they are used and provide timely reminders, thereby avoiding waste of gas fees and reducing the risk of property loss of contract accounts.

In some embodiments, the detection method for smart contract event logs includes:

Obtain the target contract; the target contract is compiled using the Solidity language;

Analyze the Solidity code of the target contract to determine the event problem status of the Solidity code; the event problem status includes at least one of an event in which variables need to be optimized in the Solidity code, an event usage frequency of the Solidity code is greater than a usage frequency threshold, an event in which parameter information is incorrect in the Solidity code, a redundant event in the Solidity code, a used debug event in the Solidity code, and an event in which a call location error exists in the Solidity code;

Based on the event problem status, a reminder message is output.

In some embodiments, the detection device for smart contract event logs includes a processor and a memory storing program instructions, and the processor is configured to execute the above-mentioned detection method for smart contract event logs when running the program instructions.

In some embodiments, the storage medium stores program instructions, and when the program instructions are run, they execute the above-mentioned detection method for smart contract event logs.

The present disclosure provides a method, device and storage medium for detecting smart contract event logs, which can achieve the following technical effects:

After obtaining the target contract compiled in the Solidity language, the Solidity code of the target contract can be analyzed to determine the event problem status of the Solidity code. Among them, the event problem status may include events in the Solidity code that require variable optimization, events in the Solidity code that use a frequency greater than a frequency threshold, events in the Solidity code that have parameter information errors, redundant events in the Solidity code, debug events that have been used in the Solidity code, and at least one of events in the Solidity code that have call location errors. Then, reminder information can be output based on the event problem status. In this way, the Solidity code can be analyzed from the perspective of the above six event problem states to detect events in the Solidity code, promptly discover problems therein, and promptly inform developers by outputting reminder messages, thereby avoiding waste of gas fees as much as possible and reducing the risk of property loss of contract accounts.

The above general description and the following description are exemplary and explanatory only and are not intended to limit the present application.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments are exemplarily described by corresponding drawings, which do not limit the embodiments. Elements with the same reference numerals in the drawings are shown as similar elements, and the drawings do not constitute a scale limitation, and wherein:

FIG1 is a schematic diagram of a detection method for a smart contract event log provided by an embodiment of the present disclosure;

FIG2 is a schematic diagram of a method for determining an event problem status of a Solidity code provided by an embodiment of the present disclosure;

FIG3 is a schematic diagram of another method for determining an event problem status of a Solidity code provided by an embodiment of the present disclosure;

FIG4 is a schematic diagram of another method for determining an event problem status of a Solidity code provided by an embodiment of the present disclosure;

FIG5 is a schematic diagram of another method for determining an event problem status of a Solidity code provided by an embodiment of the present disclosure;

FIG6 is a schematic diagram of another method for determining an event problem status of a Solidity code provided by an embodiment of the present disclosure;

FIG7 is a schematic diagram of another method for determining an event problem status of a Solidity code provided by an embodiment of the present disclosure;

FIG8 is a schematic diagram of a detection device for a smart contract event log provided in an embodiment of the present disclosure.

Detailed ways

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

The terms "first", "second", etc. in the specification and claims of the embodiments of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged where appropriate, so as to describe the embodiments of the embodiments of the present disclosure described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

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

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

The term "and/or" is a description of the association relationship between objects, indicating that three relationships can exist. For example, A and/or B means: A or B, or, A and B.

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

The embodiments of the present disclosure do not limit the execution subject of the detection method for smart contract event logs. For example, the detection method for smart contract event logs in the embodiments of the present disclosure can be applied to data processing devices such as terminal devices or servers. Among them, the terminal device refers to an electronic device with a wireless connection function. In some embodiments, the terminal device is, for example, a mobile device, a computer, or a vehicle-mounted device built into a hover car, or any combination thereof. Mobile devices may include, for example, mobile phones, smart home devices, wearable devices, smart mobile devices, virtual reality devices, etc., or any combination thereof, wherein wearable devices include, for example: smart watches, smart bracelets, pedometers, etc.

As shown in FIG1 , the present disclosure provides a method for detecting a smart contract event log, including:

S101, obtain the target contract.

Among them, the target contract is compiled in Solidity language.

S102, analyzing the Solidity code of the target contract to determine the event problem status of the Solidity code.

In the disclosed embodiment, the event problem status includes at least one of an event in which variables need to be optimized in the Solidity code, an event usage frequency of the Solidity code is greater than a usage frequency threshold, an event in which parameter information is incorrect in the Solidity code, a redundant event in the Solidity code, a used debug event in the Solidity code, and an event in which a call location error exists in the Solidity code.

S103: Output reminder information based on the event problem status.

In the embodiments of the present disclosure, for ease of understanding, the determination process of the above six event problem states and the output of reminder information may be exemplarily described in conjunction with the accompanying drawings.

Specifically, in conjunction with FIG. 2 , the process of determining the event problem state of an event that requires variable optimization in the Solidity code, that is, step S102, may specifically include steps 21A to 24A:

Step 21A: Segment the Solidity code to obtain segmentation code.

In practical applications, the Solidity code can be segmented using spaces and line breaks as delimiters, and the punctuation marks in the Solidity code can be filtered to obtain the segmented code.

Step 22A: Perform part-of-speech tagging on the word segmentation code to obtain a word segmentation tagging result.

Specifically, in the embodiments of the present disclosure, a corpus can be pre-set to be established, and the corpus can store the part-of-speech types of Solidity codes. For example, the part-of-speech types can include keywords, state variables, local variables, event names, function names, and class names. In this way, the above-mentioned word segmentation codes can be tagged according to the part-of-speech types to obtain the word segmentation tagging results.

Step 23A: Based on the word segmentation and tagging results, determine the first event from the Solidity code.

The first event includes state variables; the state variables are stored as storage type. In practical applications, since variables of storage type consume more gas than local variables of memory type, based on the above word segmentation and annotation results, events involving state variables of storage type in Solidity code can be identified as the first event, so as to facilitate subsequent processing of the first event with high gas consumption.

Step 24A: If the first function where the first event is located includes local variables, and the values of the state variables and the local variables are the same, it is determined that the event problem state is an event that requires variable optimization in the Solidity code.

Here, local variables are stored as memory type. Since memory type local variables consume less gas than storage type state variables, when the first function includes local variables and the values of the state variables and local variables are the same, it can be determined that there is an event in the Solidity code that requires variable optimization, that is, the state variables in the first event need to be optimized.

Based on the above steps 21A to 24A, in the embodiment of the present disclosure, the reminder information output based on the event problem status may specifically include: warning information indicating that variable optimization can be performed, information on the state variables of the identified first event, and information on local variables that can replace the state variables.

Furthermore, after outputting the reminder message, the detection method for smart contract event logs may also include: replacing the state variable stored in the first event as a storage type with a local variable stored in a memory type. As mentioned above, the gas consumed by the local variable stored in the memory type is lower than that of the state variable stored in the storage type, and since the values of the state variable and the local variable are the same, replacing the state variable with a local variable will not change the definition and value of the state variable, nor will it affect the persistence of the state variable on the blockchain. Therefore, data resources can be saved by variable replacement.

As shown in FIG. 3 , the process of determining the event problem state that the event usage of the Solidity code is greater than the usage threshold, that is, step S102, may specifically include steps 21B to 23B:

Step 21B: Preprocess the Solidity code to obtain preprocessed code.

In practical applications, preprocessing is used to remove the dead parts in Solidity code, which include comments and/or blank lines in Solidity code.

Step 22B: Perform word frequency analysis on the preprocessing code to obtain event usage in the preprocessing code.

Specifically, in the disclosed embodiment, the total number of lines of preprocessing code can be calculated first, and then the preprocessing code can be segmented, and the word frequency analysis can be performed on the preprocessing code after segmentation to obtain the number of times the event is called. Then, based on the number of times the event is called and the total number of lines of preprocessing code, the average number of occurrences of the event in each line of preprocessing code can be determined as the frequency of event use. Among them, since the "emit" keyword is followed by the event name in the Solidity code, the number of times the event is called can be determined by counting the number of occurrences of the keyword "emit". In addition, the frequency of event use can be obtained by dividing the number of occurrences of the event by the total number of lines of preprocessing code.

Step 23B: If the event usage frequency is greater than the usage frequency threshold, it is determined that the event problem state is that the event usage frequency of the Solidity code is greater than the usage frequency threshold.

In the embodiments of the present disclosure, the inventors have found through creative research that the average value of the event usage frequency is 0.022. Therefore, in practical applications, the value range of the usage frequency threshold may be 0.03 to 0.06, preferably 0.05.

Based on the above steps 21B to 23B, in the disclosed embodiment, the reminder information output based on the event problem status may specifically include: warning information for indicating excessive use of events. Although events are an effective way to interact with other systems, they also use a lot of resources and have a great impact on the working effect of the contract. Therefore, in the disclosed embodiment, through the event excessive warning method, developers can be informed in time to use events with caution, thereby avoiding waste of resources.

As shown in FIG. 4 , the process of determining the event problem state of the event that the parameter information inputted into the Solidity code is incorrect, that is, step S102, may specifically include steps 21C to 24C:

Step 21C: Perform static code analysis on the Solidity code to obtain the abstract syntax tree of the target contract.

In practical applications, the implementation process of static code analysis on Solidity code can adopt any existing or future static code analysis algorithm, which is not specifically limited here.

Step 22C: According to the function declaration in the abstract syntax tree, determine a second event whose number of parameters is greater than or equal to the number threshold, and obtain parameter information passed in by the second event.

Here, the quantity threshold may be 3, so as to avoid the accidental probability caused by a small number of parameters. The parameter information may include a parameter name and a parameter value.

Step 23C: From the functions in the abstract syntax tree, obtain a second function with the same number of parameters as when the second event is called.

Step 24C: If the parameter information of any parameter when the second event is called is different from the parameter information of the second function, and the parameter information of other parameters except any parameter is the same as the parameter information of the second function, then the event problem status is determined to be an event in which parameter information error exists in the Solidity code.

Thus, by determining the second event with the number of parameters greater than or equal to 3 and obtaining the parameter name and parameter value passed in by the second event, it is helpful to locate the specific function as much as possible. When the parameter information of the second event and the second function is different, it indicates that there is a parameter error.

Based on the above steps 21C-24C, in the disclosed embodiment, the reminder information output based on the event problem status may specifically include: warning information indicating parameter information errors, and related information of the second event and the second function. When calling an event, if the incoming error parameter is consistent with the parameter type when it is defined, the compiler cannot find the error in the parameter information. After the smart contract is deployed, the error is difficult to change. Therefore, by detecting the incoming parameter error and warning, the developer can be informed in time, which helps to minimize the risk of contract vulnerabilities.

As shown in FIG. 5 , the process of determining the event problem state of the redundant event in the Solidity code, that is, step S102, may specifically include steps 21D to 22D:

Step 21D: For the third event called in the Solidity code, determine a fourth event including all parameters of the third event from the called events included in the Solidity code except the third event.

Specifically, the number of fourth events can be one or more. The fourth event includes all parameters of the third event, which may mean that the parameters of the two are the same, or the parameters of the fourth event include the parameters of the third event. Based on this, in the embodiment of the present disclosure, for the third event, it can be queried in the Solidity code whether there are other called events whose parameters include the parameters of the third event. If so, the event can be determined as the fourth event. In addition, since the alias analysis algorithm is a technology for identifying sets of program variable names, these name sets may cause the same memory location during program execution, and parameters with the same memory location can also be regarded as the same parameters. Therefore, in the embodiment of the present disclosure, the parameters of the third event can be further analyzed by the alias analysis algorithm to determine the parameters with the same memory location, and further determine the corresponding fourth event based on the parameters with the same memory location.

Step 22D: When the parameter value of the third event is the same as the corresponding parameter value in the fourth event, it is determined that the event problem state is that there are redundant events in the Solidity code.

As mentioned above, the fourth event includes the third event. Therefore, when the parameter value of the third event is the same as the parameter value of the fourth event, it can be explained that the third event is a redundant event for the fourth event.

Based on the above steps 21D to 22D, in the embodiment of the present disclosure, the reminder information output based on the event problem state may specifically include: warning information indicating the existence of redundant events, and related information of the third event and the fourth event. Since the third event is a redundant event, it is included in the fourth event, and the parameter value is also the same. Therefore, by detecting redundant events and issuing warnings, developers can be informed in a timely manner, thereby helping to cancel the call of redundant events as soon as possible to reduce the consumption of data resources.

As shown in FIG. 6 , the process of determining the event problem state of the used debug event in the Solidity code, that is, step S102, may specifically include steps 21E to 22E:

Step 21E: Analyze the Solidity code to determine whether at least one of the fifth event, the sixth event, and the seventh event exists in the Solidity code.

Among them, the fifth event is an empty event; the sixth event is an event that is called at different locations and records the same variable; the seventh event is an event that includes a string parameter, and the string parameter includes a preset keyword. In actual applications, developers can use events for debugging. The form of debugging events can be reflected as an empty event, an event that is called at different locations and records the same variable, or an event that includes a string parameter, and the string parameter includes a preset keyword, that is, at least one of the fifth event, the sixth event, and the seventh event. In actual applications, the preset keyword can be reflected as at least one of "debugging", "test" and "help".

Step 22E: If at least one of the fifth event, the sixth event, and the seventh event exists in the Solidity code, it is determined that the event problem state is that there is a used debug event in the Solidity code.

Based on the above content, it can be known that when at least one of the fifth event, the sixth event and the seventh event exists in the Solidity code, it can be explained that the developer did not delete the used debugging event after debugging the Solidity code.

Based on the above steps 21E-22E, in the disclosed embodiment, the reminder information output based on the event problem status may specifically include: warning information for indicating the debug events that have been used in the Solidity code. After the developer uses the event to debug the code, if the debug events that are no longer needed are not deleted in time, it will have a negative impact on the readability of the code and cause unnecessary data resource consumption. Therefore, by detecting the debug events that have been used in the Solidity code and warning, the developer can be informed in time, which helps the developer to delete the used debug events as soon as possible to reduce the consumption of data resources.

As shown in FIG. 7 , the process of determining the problem state of the event that there is a call location error in the Solidity code, that is, step S102, may specifically include steps 21F-24F:

Step 21F: During the execution of the Solidity code, obtain the execution path and operation code of the Solidity code.

In the disclosed embodiment, in order to run the Solidity code, you can first use Anvil (a blockchain running tool) to build a network test environment for the local blockchain, and deploy the target contract in the network test environment. Then, you can randomly generate valid inputs for the functions of the target contract. Specifically, you can first compile the target contract to generate a JSON format file corresponding to its Application Binary Interface (ABI), and then parse the ABI file to obtain the function description and parameter data types, and then determine the input domain of the parameters of each data type according to the Solidity official document.

For example, for parameters of fixed-length data types, such as int, uint, bytes, and fixed array types, inputs can be randomly generated within their valid input domain.

For parameters of data types with non-fixed length, such as parameters of string type, you can first randomly generate a positive integer within a valid range as the length, and then randomly generate a string of the length as input.

For address type parameters, ABI function feature analysis is required, that is, extracting all function signatures declared in the ABI, and then calculating the function selector of each function signature, that is, the Keccak hash (SHA-3) of the first four bytes of the function signature, to determine the function selector used by each public ABI function. Next, a mapping can be constructed and stored, which uses the function selector as the key and the addresses of all smart contracts with the same function selector as the value. Through this mapping, for each function selector, all smart contract addresses that support the function selector can be found by searching the mapping, and thereby generating random inputs for parameters of the address data type for each ABI function of the smart contract.

Step 22F: After the eighth event in the Solidity code is called, detect whether the variable passed in by the eighth event is reassigned through the execution path and operation code.

Here, the eighth event is any event in the Solidity code. In the disclosed embodiment, the program stubbing technology can be used to obtain the execution path using branch coverage probes and condition coverage probes, and the opcodes of the target contract when it is executed on the EVM can be monitored to detect whether the variables passed in by the eighth event are reassigned after the eighth event is called.

Step 23F: If the variable passed in by the eighth event is reassigned, check whether there is a ninth event in the Solidity code for recording the reassignment result of the eighth event.

In actual applications, events are usually called after a certain operation is completed, for example, to record transaction, assignment or authorization information. Based on this, by detecting the ninth event, that is, the event used to record the reassigned variable, it can be determined whether the event is called again after the corresponding operation is executed.

Step 24F: If the ninth event does not exist in the Solidity code, it is determined that the event problem state is an event with a call location error in the Solidity code.

If the ninth event does not exist, it means that after the eighth event is called, it is reassigned but not called again, that is, its calling position is wrong.

Based on the above steps 21F to 24F, in the disclosed embodiment, the reminder information output based on the event problem status may specifically include: warning information indicating that there is a call location error in the Solidity code. In this way, by detecting the call location error of the event and issuing a warning, the developer can be informed in a timely manner, thereby helping to minimize the risk of contract vulnerabilities.

A detection method for smart contract event log provided by an embodiment of the present disclosure is adopted. After obtaining the target contract compiled by the Solidity language, the Solidity code of the target contract can be analyzed to determine the event problem status of the Solidity code. Among them, the event problem status may include events in the Solidity code that require variable optimization, events in the Solidity code that use frequency is greater than the use frequency threshold, events in the Solidity code that have parameter information errors, redundant events in the Solidity code, debug events that have been used in the Solidity code, and at least one of events in which there is a call location error in the Solidity code. Then, a reminder message can be output based on the event problem status. In this way, the Solidity code can be analyzed from the perspective of the above six event problem states to detect events in the Solidity code, promptly discover problems therein, and promptly inform the developer by outputting a reminder message, thereby avoiding the waste of data resources as much as possible and reducing the risk of property loss of the contract account.

As shown in FIG8 , the embodiment of the present disclosure provides a detection device 300 for a smart contract event log, including a processor 304 and a memory 301. Optionally, the device may also include a communication interface 302 and a bus 303. The processor 304, the communication interface 302, and the memory 301 may communicate with each other through the bus 303. The communication interface 302 may be used for information transmission. The processor 304 may call the logic instructions in the memory 301 to execute the detection method for the smart contract event log of the above embodiment.

In addition, the logic instructions in the memory 301 described above can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product.

The memory 301 is a computer-readable storage medium that can be used to store software programs and computer executable programs, such as program instructions/modules corresponding to the method in the embodiment of the present disclosure. The processor 304 executes the functional application and data processing by running the program instructions/modules stored in the memory 301, that is, the detection method for the smart contract event log in the above embodiment is implemented.

The memory 301 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 301 may include a high-speed random access memory and may also include a non-volatile memory.

An embodiment of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute the above-mentioned detection method for smart contract event logs.

The computer-readable storage medium mentioned above may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

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

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

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

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

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

Claims (9)

1. A method for detecting an intelligent contract event log, comprising:

Acquiring a target contract; compiling the target contract by adopting Solidity language;

analyzing Solidity codes of the target contracts and determining event problem states of the Solidity codes; the event problem state comprises at least one of an event in the Solidity code that requires an optimization variable, an event in the Solidity code that uses more frequently than a frequency of use threshold, an event in the Solidity code that has parameter information errors, a redundant event in the Solidity code, a used debug event in the Solidity code, and an event in the Solidity code that has call position errors;

outputting reminding information based on the event problem state;

Wherein the analyzing Solidity codes of the target contracts to determine event issue status of the Solidity codes comprises:

performing word segmentation on the Solidity codes to obtain word segmentation codes;

part of speech tagging is carried out on the word segmentation codes, and word segmentation tagging results are obtained;

Determining a first event from the Solidity codes based on the word segmentation annotation result; the parameters when the first event is invoked include a state variable; the state variables are stored in a storage type;

if the first function where the first event is located includes a local variable and the values of the state variable and the local variable are the same, determining that the event problem state is that an event requiring an optimized variable exists in the Solidity codes; the local variables are stored in a memory type.

2. The method of claim 1, wherein the analyzing Solidity codes of the target contracts to determine event issue status of the Solidity codes further comprises:

preprocessing the Solidity codes to obtain preprocessed codes; the preprocessing is used to remove inactive portions in the Solidity code, including notes and/or empty rows in the Solidity code;

word frequency analysis is carried out on the preprocessing codes, so that event use frequency in the preprocessing codes is obtained;

And if the event using frequency is larger than the using frequency threshold value, determining that the event problem state is that the event using frequency of Solidity codes is larger than the using frequency threshold value.

3. The method of claim 1, wherein the analyzing Solidity codes of the target contracts to determine event issue status of the Solidity codes further comprises:

performing static code analysis on the Solidity codes to obtain an abstract syntax tree of the target contract;

Determining a second event with the parameter number larger than or equal to a number threshold according to the function statement in the abstract syntax tree, and acquiring parameter information transmitted by the second event;

Determining Solidity a second function in the code that is the same as the number of parameters when the second event is invoked based on the abstract syntax tree;

And if the parameter information of any parameter when the second event is called is different from the parameter information of the second function, and the parameter information of other parameters except for any parameter is the same as the parameter information of the second function, determining that the event problem state is the event with parameter information errors in the Solidity codes.

4. The method of claim 1, wherein the analyzing Solidity codes of the target contracts to determine event issue status of the Solidity codes further comprises:

For a third event called in Solidity codes, determining a fourth event containing all parameters of the third event from called events except the third event included in the Solidity codes;

And when the parameter value of the third event is the same as the corresponding parameter value in the fourth event, determining that the event problem state is that a redundant event exists in the Solidity codes.

5. The method of claim 1, wherein the analyzing Solidity codes of the target contracts to determine event issue status of the Solidity codes further comprises:

analyzing the Solidity code to determine if at least one of a fifth event, a sixth event, and a seventh event is present in the Solidity code; the fifth event is an empty event; the sixth event is an event which is called at a different position and records the same variable; the seventh event is an event comprising a character string parameter, and the character string parameter comprises a preset keyword;

If at least one of a fifth event, a sixth event, and a seventh event exists in the Solidity code, determining that the event issue state is that the used debug event exists in the Solidity code.

6. The method of claim 1, wherein the analyzing Solidity codes of the target contracts to determine event issue status of the Solidity codes further comprises:

Acquiring an execution path and an operation code of the Solidity code in the running process of the Solidity code;

After the eighth event in Solidity codes is called, detecting whether variables transmitted by the eighth event are reassigned or not through the execution path and the operation code;

If the variable transmitted by the eighth event is reassigned, detecting whether a ninth event for recording reassignment results of the eighth event exists in the Solidity codes;

And if the ninth event does not exist in the Solidity codes, determining that the event problem state is the event with the calling position error in the Solidity codes.

7. The method according to claim 1, wherein after outputting the alert information based on the event question status, the method further comprises:

and replacing the state variable stored in the storage type in the first event with the local variable stored in the memory type.

8. A detection apparatus for a smart contract event log, comprising a processor and a memory storing program instructions, wherein the processor is configured, when executing the program instructions, to perform the detection method for a smart contract event log as claimed in any one of claims 1 to 7.

9. A storage medium storing program instructions which, when executed, perform the method for detecting a smart contract event log according to any one of claims 1 to 7.