Untested verification method for Ethereum smart contract return value based on dynamic transaction information

Abstract

The present invention discloses a method for verifying the return value of an Ethereum smart contract based on dynamic transaction information, including executing an Ethereum transaction replay operation based on a platform above Ethereum 2.0 and recording the operation code information of the replayed transaction; extracting the key logic of the operation code information and performing a transaction execution simulation process, collecting data information after the transaction simulation; extracting the required key operation code information from the data information, and converting it into a data file that can be identified by a logic relationship detector; constructing a logic relationship detector based on Datalog, and using the constructed logic relationship detector and the detection rules and data files pre-formulated therein to detect whether the replayed transaction has a return value undetected problem. The present invention can fully simplify the logic of the detection rules, expand the detection range and improve the detection accuracy, without worrying about the state space explosion problem, and the use of a dynamic verification method can ensure the efficiency and accuracy of the verification.

Description

Technical Field

[0001] The present invention belongs to the technical field of dynamic verification of smart contracts, and in particular relates to an untested verification method for return values ​​of Ethereum smart contracts based on dynamic transaction information. Background Art

[0002] At present, Ethereum has been developed into the largest blockchain development platform and is still developing rapidly. One of the important criteria for calling Ethereum the blockchain 2.0 era is that we can use smart contracts in various scenarios, such as financial derivatives, insurance, real estate, legal procedures, etc. Smart contracts give decentralized applications built on Ethereum unlimited imagination and strong vitality, but at the same time, security issues in the development of smart contracts have become more and more serious. Since many smart contracts are deployed without verification, a large number of smart contracts may have serious security risks and even lead to hacker attacks. One typical case is the problem of undetected return values.

[0003] The problem of unchecked return values ​​mostly occurs in smart contracts related to transfer transactions. Therefore, if a smart contract with unchecked return values ​​encounters a transfer failure, it is very likely to cause economic losses. On the decentralized platform of Ethereum, once economic losses occur, they are mostly irreversible. Therefore, the security verification of smart contracts is crucial.

[0004] In smart contracts, unchecked return values ​​mainly occur after a function call or a smart contract call, which may cause the function or smart contract call to fail but the subsequent code continues to execute, resulting in errors. Since the defect of unchecked return values ​​can be easily exploited by hackers and cause economic losses, it is very necessary to verify the unchecked return values ​​of smart contracts.

[0005] Most of the existing smart contract security detection tools are static detection tools, that is, they detect smart contracts that have not yet been actually deployed. However, since there is no real running smart contract, it is difficult for static detection tools to achieve both efficiency and accuracy. Specifically, on the one hand, static detection tools may have the problem of verification state space explosion, and on the other hand, static detection tools are difficult to detect mutual calls of smart contracts. Therefore, for the situation where the return value in the smart contract is not detected, the existing static tools still have great shortcomings.

[0006] In addition, the Ethereum platform completed a platform upgrade on September 15, 2022. The consensus mechanism was upgraded from the original proof-of-work mechanism to the proof-of-stake mechanism, and the node synchronization mechanism was also changed. These two major changes make it difficult for existing smart contract dynamic detection tools to directly detect the latest Ethereum transactions.

[0007] After the above analysis, the main problems and defects of the existing technology for the problem of undetected return values ​​of Ethereum smart contracts are:

[0008] (1) Most existing technologies are static detection tools, which need to verify all possible execution branches in smart contracts that have not yet been deployed. This is prone to the problem of explosion of the verification state space and is difficult to detect the mutual calls of smart contracts. Therefore, it is impossible to ensure the efficiency and accuracy of verification at the same time.

[0009] (2) Existing dynamic verification tools cannot adapt to the changes in the consensus mechanism and node synchronization mechanism caused by the upgrade of the Ethereum platform, and it is difficult to directly detect the latest Ethereum transactions.

[0010] The difficulty in solving the above problems and defects is as follows: the logic of some smart contracts is relatively complex, and the static analysis of smart contracts can easily lead to the problem of state space explosion; in addition, for calls between smart contracts, it is impossible to know the specific execution status of the called smart contract without actually executing the deployed smart contract, so it is impossible to perform security verification on the called smart contract; on the other hand, the changes in the consensus mechanism and node synchronization mechanism caused by the upgrade of the Ethereum platform require the implementation of a new plug-in module to obtain relevant dynamic information generated by the operation of the smart contract.

[0011] The significance of solving the above problems and defects is that due to the decentralized nature of the Ethereum platform, transactions generated by Ethereum smart contracts cannot be revoked once they are generated. Therefore, it is very necessary to verify the security of smart contracts, especially for the problem of undetected return values ​​that are easily exploited by hackers. In addition, in the case of undetected return values, mutual calls of smart contracts are very common. Therefore, accurate and efficient security verification of smart contracts with mutual calls can greatly increase the coverage of undetected return value verification and ensure the security of Ethereum smart contracts. Summary of the invention

[0012] In order to solve the above problems existing in the prior art, the present invention provides an Ethereum smart contract return value untested verification method based on dynamic transaction information. The technical problem to be solved by the present invention is achieved through the following technical solutions:

[0013] In a first aspect, an embodiment of the present invention provides an Ethereum smart contract return value untested verification method based on dynamic transaction information, the method comprising:

[0014] Execute Ethereum transaction replay operations based on Ethereum 2.0 and above platforms and record the operation code information of the replayed transaction;

[0015] Extract the key logic of the operation code information and simulate the transaction execution process, and collect the data information after the transaction simulation;

[0016] Extracting the required key operation code information from the data information and converting it into a data file that can be recognized by the logic relationship detector;

[0017] A logic relationship detector is constructed based on Datalog, and the constructed logic relationship detector and the detection rules pre-established therein and the data file are used to detect whether there is a problem of undetected return values ​​in the replayed transaction.

[0018] In one embodiment of the present invention, the step of performing an Ethereum transaction replay operation based on a platform above Ethereum 2.0 and recording the operation code information of the replayed transaction includes:

[0019] By synchronizing the nodes of the Ethereum network and modifying the source code of the Ethereum execution layer client in a preset manner, the executed transactions are replayed, and the operation code information of the replayed transactions is stored in the data set.

[0020] In one embodiment of the present invention, the method of synchronizing the nodes of the Ethereum network includes:

[0021] The execution layer uses the full synchronization mode for synchronization, and the consensus layer uses the optimistic synchronization mode for synchronization.

[0022] In one embodiment of the present invention, the recorded and replayed transaction operation code information includes:

[0023] The name of the opcode, the execution parameters of the opcode, and the location identification value of the opcode.

[0024] In one embodiment of the present invention, the key logic of extracting the operation code information and performing a transaction execution simulation process, and collecting data information after the transaction simulation, includes:

[0025] Execute data dependency partitioning, including assigning unified specific parameters to data with dependencies according to the relative positions of the opcodes in the contract to achieve encoding of dependencies between data, and assigning an opcode location value to each opcode to distinguish data without dependencies; wherein the specific parameters include depth and number of calls;

[0026] According to the result after the data dependency partitioning process, the transaction execution simulation process is performed based on the stack operation of the simulated Ethereum virtual machine EVM, and the data information after the transaction simulation is collected.

[0027] In one embodiment of the present invention, the step of extracting the required key operation code information from the data information and converting it into a data file that can be recognized by the logic relationship detector includes:

[0028] According to different information types, extract the information of all key operation codes in the replay transaction from the data information to obtain key operation code information of various types; wherein the key operation codes include call, callcode, delegatecall and jumpi;

[0029] Each type of key operation code information is classified and stored in a data file.

[0030] In one embodiment of the present invention, the use of the constructed logical relationship detector and the pre-defined detection rules therein and the data file to detect whether the replayed transaction has a return value undetected problem includes:

[0031] According to the usage record requirement of the parameter in the detection rule, the call, callcode and delegatecall operation codes in the data file are first screened to obtain a first result file;

[0032] Using the first result file, based on the requirements of the depth and the operation code location value in the detection rule, the call, callcode and delegatecall operation codes are matched with the jump operation code to obtain the information of the call, callcode and delegatecall operation codes with return value detection indicating successful matching, and store it in the second result file;

[0033] The first result file and the second result file are matched to obtain call, callcode and delegatecall opcodes without jumpi matching as opcodes with undetected return values, and information of these opcode calls is stored in the final result file.

[0034] In a second aspect, an embodiment of the present invention provides an Ethereum smart contract return value untested verification device based on dynamic transaction information, the device comprising:

[0035] The transaction replay recording module is used to perform Ethereum transaction replay operations based on Ethereum 2.0 and above platforms and record the operation code information of the replayed transaction;

[0036] The simulated transaction execution module is used to extract the key logic of the operation code information and perform the transaction execution simulation process, and collect the data information after the transaction simulation;

[0037] A key information extraction module, used to extract the required key operation code information from the data information and convert it into a data file that can be recognized by the logic relationship detector;

[0038] The return value undetected verification module is used to construct a logic relationship detector based on Datalog, and use the constructed logic relationship detector and the pre-defined detection rules and the data file to detect whether the replayed transaction has a return value undetected problem.

[0039] In a third aspect, an embodiment of the present invention provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0040] The memory is used to store computer programs;

[0041] The processor is used to implement the steps of the Ethereum smart contract return value untested verification method based on dynamic transaction information provided by an embodiment of the present invention when executing the program stored in the memory.

[0042] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the untested verification method of the return value of an Ethereum smart contract based on dynamic transaction information provided in the embodiment of the present invention are implemented.

[0043] Beneficial effects of the present invention:

[0044] In an Ethereum smart contract return value unchecked verification method based on dynamic transaction information provided by an embodiment of the present invention: first, an Ethereum transaction transaction replay operation based on an Ethereum 2.0 or higher platform is performed and the operation code information of the replayed transaction transaction is recorded; secondly, the key logic of the operation code information is extracted and a transaction execution simulation process is performed, and the data information after the transaction simulation is collected; then, the required key operation code information is extracted from the data information, and converted into a data file that can be recognized by a logical relationship detector; finally, a logical relationship detector is constructed based on Datalog, and the constructed logical relationship detector and the pre-defined detection rules therein and the data file are used to detect whether the replayed transaction has a return value unchecked problem, so as to realize the marking of transactions with unchecked return values.

[0045] Since the embodiment of the present invention uses a logic rule detector constructed based on datalog, the construction of logic rules can be more free, so the constructed logic rules can be more targeted, and the detection rules formulated for the problem of undetected return values ​​are more concise, thereby fully simplifying the logic of the detection rules. Since the conciseness of the generated data file reduces the amount of data to be analyzed, the detection speed can be improved. In addition, during the operation code information extraction and analysis stage, the embodiment of the present invention considers more operation codes that may cause the problem of undetected return values, thereby expanding the detection range and improving the accuracy of detection due to the increase in the detection range.

[0046] Moreover, since the collection of opcode information in the embodiment of the present invention is based on the replay of executed transactions, there is no need to worry about the state space explosion problem. In addition, for transactions in which smart contracts call each other, the transaction can be tracked through the replay record of the transaction, thereby verifying whether there is a problem of undetected return value. Before the merger of Ethereum, users do not need to run a local execution layer client, but only need to use a server similar to Infura to access the Ethereum network; after the merger, users must run an execution layer client, and only when the execution layer client and the consensus layer client run together can they access the Ethereum network. The execution layer is responsible for processing transaction transactions and data, and the consensus layer is responsible for processing the POS consensus mechanism, so the consensus layer needs to be synchronized to detect the latest Ethereum transaction. Therefore, the embodiment of the present invention can be applied to the undetected return value verification of Ethereum smart contracts.

[0047] At the same time, since the embodiment of the present invention belongs to the field of dynamic verification technology of smart contracts, and the verified transactions are transactions that actually exist in reality, the dynamic verification method is applied to detect whether there is a problem of undetected return values ​​in the actual transactions, so that the corresponding parameters of each operation code when the smart contract is running are determined, and the execution status of each branch is determined, thereby effectively ensuring the efficiency and accuracy of smart contract verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 A flowchart of an untested verification method for an Ethereum smart contract return value based on dynamic transaction information provided by an embodiment of the present invention;

[0049] Figure 2 A schematic diagram of the execution logic of the logic relationship detector provided in an embodiment of the present invention to detect the return value;

[0050] Figure 3 A schematic diagram of the structure of an untested verification device for an Ethereum smart contract return value based on dynamic transaction information provided by an embodiment of the present invention;

[0051] Figure 4The present invention is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0052] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0053] Below, firstly, an untested verification method for an Ethereum smart contract return value based on dynamic transaction information provided by an embodiment of the present invention is introduced.

[0054] like Figure 1 As shown, the Ethereum smart contract return value undetected verification method based on dynamic transaction information provided by the embodiment of the present invention is actually a verification method for the Ethereum smart contract return value undetected based on dynamic transaction information, which may include the following steps S1 to S4:

[0055] S1, execute the Ethereum transaction replay operation based on the Ethereum 2.0 platform and above and record the operation code information of the replayed transaction;

[0056] It is understandable to those skilled in the art that Ethereum completed the merger on September 15, 2022 and upgraded to Ethereum 2.0. The consensus mechanism has changed from the original proof of work to proof of stake, and the mechanism for synchronizing nodes has also changed. Before the merger, users did not need to run a local execution client, but only needed to use a server similar to Infura to access the Ethereum network; after the merger, users must run an execution layer client, and only when the execution layer client and the consensus layer client run together can they access the Ethereum network. The execution layer is responsible for processing transactions and data, and the consensus layer is responsible for processing the POS consensus mechanism.

[0057] Since the consensus mechanism in Ethereum 2.0 is transferred from PoW to PoS, the Ethereum 2.0 network has a beacon chain and 1024 shard chains to achieve expansion. These different shard chains can communicate with each other and are uniformly controlled and verified by the main chain beacon chain. It is mandatory to update the client to version 1.10 or above to join the main network and further synchronize the full node to extract bytecode. Therefore, this method of dynamically obtaining transaction information can be used all the time if the consensus mechanism of Ethereum and the method of synchronizing the full node do not change in the future. Therefore, the scope of application of the embodiment of the present invention includes Ethereum 2.0 and new platform versions developed subsequently.

[0058] Regarding the selection of the execution layer client and the consensus layer client, according to the statistics of the usage rate of each client on the Ethereum official website Client Diversity, the embodiment of the present invention preferentially selects the combination of the top-ranked execution layer client Geth + consensus layer client Prysm, which has the highest usage rate and a more comprehensive and friendly community update. Specifically, the execution subject of the method of the embodiment of the present invention can be the execution layer client.

[0059] In S1, the operation of replaying Ethereum transactions based on Ethereum 2.0 or higher platforms and recording the operation code information of the replayed transactions is to provide the required logical relationship of smart contract execution for the subsequent dynamic verification framework. The operation of replaying Ethereum transactions based on Ethereum 2.0 or higher platforms and recording the operation code information of the replayed transactions includes:

[0060] By synchronizing the nodes of the Ethereum network and modifying the source code of the Ethereum execution layer client in a preset manner, the executed transactions are replayed, and the operation code information generated when replaying the transactions is stored in the data set.

[0061] In an embodiment of the present invention, to obtain information at the bytecode level during the Ethereum smart contract transaction processing, it is necessary to replay the executed transactions by synchronizing the nodes of the Ethereum network and modifying the source code of the Ethereum execution layer client to extract the transaction records, generate the operation code information of the transaction, and store these together with the relevant data in the data set. Among them, the bytecode is a byte array of hexadecimal digital encodings formed after the smart contract is compiled by the compiler. The bytecode is parsed in units of one byte, and each byte represents an EVM (Ethereum Virtual Machine, Ethereum Virtual Machine) instruction or an operation data. When executing the bytecode, EVM further converts the bytecode into an operation code that the operating system can understand. Therefore, the bytecode can be understood as a bridge between the smart contract and the EVM level, and the operation code can be understood as a bridge between the EVM and the operating system and the hardware.

[0062] In order to obtain complete transaction operation code information, in an embodiment of the present invention, the method of synchronizing the nodes of the Ethereum network includes:

[0063] The execution layer uses the full synchronization mode for synchronization, and the consensus layer uses the optimistic synchronization mode for synchronization. For the concepts of the full synchronization mode and the optimistic synchronization mode, please refer to the relevant technical understanding, which will not be explained in detail here.

[0064] The embodiment of the present invention can use the execution layer client Geth, modify its source code part, and store the replayed transaction bytecode information in the data set.

[0065] For example, you can select the source code of the latest version of Geth 1.10.25 for modification. Specifically, in the source directory, add the mongoDB configuration file and add global variables related to transactions; in the core module, modify the applyTransaction() function and the Prefetch() function in the state_processor file and the state_prefetcher file: The function of the applyTransaction() function is to replay transactions in the EVM, collect the generated bytecode during the execution of this function, and store the bytecode and other relevant information of the transaction (such as block number, gas fee, etc.) in the local mongodb. The function of the Prefetch() function is to eliminate the redundancy generated during prefetching. Add the Boolean parameter abundant to this function. If it is false, it means to cancel prefetching, which reduces the unnecessary network overhead caused by preheating the slot. Under the vm module, modify the interpreter file and the instructions file, modify the parameters of the Run() function and the execution function corresponding to the opcode, and add a third return value of string type in the return value, that is, the necessary information corresponding to each opcode, to facilitate the subsequent analysis of the opcode parameters; modify the Stop() function of the tx_pool file, add the write operation of mongDB, and save the remaining transaction records in tx_pool to mongDB. Among them, please understand the various files, functions or variable names involved in Geth in the above text in conjunction with the existing technology, and no detailed explanation is given here. Of course, the source code modification method for other versions of Geth is similar and can be adaptively adjusted.

[0066] The recorded replayed transaction operation code information includes:

[0067] The name of the opcode, the execution parameters of the opcode, and the location identification value of the opcode.

[0068] The execution parameter of the opcode refers to the numerical value corresponding to the opcode when it is executed. For example, if the cost of executing an action is 20, the opcode refers to "cost" and the execution parameter refers to "20". The position identification value of the opcode is used to distinguish the positions of all opcodes in the same transaction.

[0069] S2, extract the key logic of the operation code information and perform transaction execution simulation process, and collect data information after transaction simulation;

[0070] In an optional implementation manner, S2 includes the following steps:

[0071] S21, performing data dependency partitioning processing, including assigning unified specific parameters to data with dependencies according to the relative positions of the operation codes in the contract to achieve encoding of dependencies between data, and assigning an operation code positioning value to each operation code to distinguish data without dependencies;

[0072] The data dependency partitioning process uses the opcode information extracted by S1 to obtain the dependency relationship between opcodes.

[0073] Specific:

[0074] First, the dependencies between data in the opcode information are encoded: according to the relative position of the opcode in the contract, the data with dependencies are assigned unified specific parameters to determine the execution order of the opcode in the actual execution process and serve as the basis for detection in the subsequent rule detection stage, where the specific parameters include depth and number of calls. Depth refers to the execution depth of the contract call; number of calls refers to the number of times the transaction calls the contract when the opcode is executed.

[0075] At the same time, in order to distinguish data that does not have a dependency relationship, the embodiment of the present invention assigns an opcode positioning value to each opcode to distinguish it from the relative position data of the opcode in the contract. Because there are multiple contracts, the relative position of the opcode in the contract as data may cause the same data between opcodes and cause detection errors. The opcode positioning value of each opcode is different. After the data dependency division is completed, the data with dependencies have the same parameters for the transaction execution simulation processing link to distinguish between opcodes.

[0076] S22, according to the result of the data dependency partitioning processing, based on the stack operation of the simulated Ethereum virtual machine EVM, the transaction execution simulation processing is performed, and the data information after the transaction simulation is collected.

[0077] The transaction execution simulation process uses the result obtained from the data dependency partitioning process to obtain further opcode information. The opcode information needs to simulate the stack operation of the Ethereum virtual machine EVM for further analysis. For some opcodes, the execution parameters of the opcodes are known in the information collection stage, and these execution parameters will be collected and pushed into the stack. For other opcodes such as jumpi and mstore, their execution parameters cannot be obtained in the information collection stage. When simulating the stack, the stack is popped, and the data obtained from the stack is the execution parameter of the opcode.

[0078] This step is to obtain more complete data information. The analysis of subsequent steps requires the execution parameters of all opcodes in order to determine more detailed connections between opcodes.

[0079] S3, extracting the required key operation code information from the data information, and converting it into a data file that can be recognized by the logic relationship detector;

[0080] S3 is used to provide the required smart contract dynamic operation information to the subsequent dynamic verification framework.

[0081] In an optional implementation manner, S3 may include:

[0082] S31, extracting information of all key operation codes in the replay transaction from the data information according to different information types, to obtain key operation code information of each type;

[0083] In this step, first, all key opcodes in the replayed transaction are found from the data information, where the key opcodes include call, callcode, delegatecall, jumpi, etc. Then, in order to use the extracted information for the detection of the logic relationship detector, different types of information of the opcodes are extracted separately, and different information types include basic information such as depth and number of calls, as well as other opcode information involved in the call of the opcode.

[0084] It should be emphasized that, for the meaning of the operation codes such as call involved in the embodiments of the present invention, please refer to the relevant technology and will not be explained here.

[0085] S32, classify and store each type of key operation code information into a data file.

[0086] It should be noted that the logic relationship detector built based on Datalog cannot directly detect the opcode information. It is necessary to extract the data of the same category in the logic relationship to generate a data file. The opcodes required for the problem of undetected return values ​​include call, callcode, delegatecall and jumpi. In addition, the parameters involved in the execution of each operation, the opcode location value, depth and number of calls are also required. These values ​​are classified and stored in the data file for subsequent logic detection.

[0087] S4, constructing a logic relationship detector based on Datalog, and using the constructed logic relationship detector and the pre-defined detection rules therein and the data file to detect whether there is a problem of undetected return value in the replayed transaction.

[0088] S4 needs to formulate detection rules based on Datalog in advance, build a logical relationship detector based on Datalog, and detect the data file given in S3, and record the undetected operation codes containing return values ​​into the final result file.

[0089] The logical relationship detector built on Datalog includes an open source Datalog engine and detection rules formulated for the problem of undetected return values. The open source Datalog engine includes an interpreter and a compiler to execute Datalog programs, and the detection rules are Datalog programs written based on the collected information and the functions that need to be completed. The logical relationship detector detects the extracted key opcode information according to the formulated detection rules, and determines whether the transaction has an undetected return value problem. If there is an undetected return value problem, the opcode information is recorded in the final result file.

[0090] In the embodiment of the present invention, the return value not detected refers to a transaction using a call, callcode or delegatecall opcode during execution, but not judging the return value after the use, that is, there is a call, callcode or delegatecall opcode without a corresponding jumpi operation. Transactions with this phenomenon are considered to have a return value not detected problem.

[0091] In order to detect transactions with this phenomenon, detection rules need to be formulated in advance, and the detection rules determine the detection order and detection results of the data files. In an optional implementation, the constructed logical relationship detector and the pre-formulated detection rules and the data files are used to detect whether the replayed transaction has the problem of undetected return values, including:

[0092] S41, performing a first screening on the call, callcode and delegatecall operation codes in the data file according to the usage record requirement of the parameter in the detection rule to obtain a first result file;

[0093] Specifically, when the detection rules are formulated, conditional screening is performed on the call, callcode and delegatecall opcodes. It is necessary to determine whether the opcode may have a matching return value detection opcode based on other opcode information involved in the opcode. Only the call, callcode and delegatecall opcodes that meet the conditions will be matched with jumpi for detection.

[0094] S41 is the first step of detecting the data file of the extracted call opcode execution related information. The detection in this step is to screen the call, callcode and delegatecall calls that meet the rules. The screening condition is that a certain parameter involved in the use of call, callcode and delegatecall calls needs to be recorded in another data file used to record the opcodes used. The information screened out in this step is stored in the first result file, where the first result file can be named s_first.

[0095] S42, using the first result file, based on the requirements of the depth and the operation code location value in the detection rule, the call, callcode and delegatecall operation codes are matched with the jump operation code to obtain the information of the call, callcode and delegatecall operation codes with return value detection that indicates a successful match and store it in the second result file;

[0096] In this step, the call, callcode, delegatecall opcodes and jumpi will also be screened. Specifically, the first result file is used to match each call, callcode and delegatecall call with the jumpi opcode. Since the matching operation is time-consuming, in order to save detection time, it is necessary to determine whether the depths of the two opcodes are consistent before performing the matching operation. Only opcodes with consistent depths can be matched. In other words, the matching opcodes must have the same depth parameters, and the opcode location value of the opcode that executes the call must be larger than the opcode location value of the opcode that executes the return value detection operation. Only those that meet the conditions after these screenings will be finally matched.

[0097] S42 stores the successfully matched operation code information into a second result file, wherein the second result file may be named s_second.

[0098] S43, matching the first result file with the second result file to obtain call, callcode and delegatecall opcodes without jumpi matching as opcodes with undetected return values, and storing the information of these opcode calls into the final result file.

[0099] The two result files obtained in S41 and S42 are matched to obtain the call, callcode and delegatecall call information without jumpi matching, and store it in the final result file, wherein the final result file can be named result.

[0100] Specifically, the call, callcode and delegatecall opcodes in S43 will be matched with the eligible jumpi opcodes. At this time, if there is a call, callcode or delegatecall that cannot be matched with any jumpi opcode, then the call, callcode or delegatecall opcode will be recorded, indicating that there is a problem of undetected return value in this transaction.

[0101] For the execution logic of the return value detected by the logical relationship detector, see Figure 2 understand. Figure 2 In the example, the initial data file is the data file provided by S3. After S41, the call, callcode, and delegatecall opcodes that can perform return value detection are obtained, and then the matching value is judged with the jump opcode in S42 to obtain all call, callcode, and delegatecall opcodes with return value detection. Finally, the result files obtained by S41 and S42 are matched to obtain call, callcode, and delegatecall opcodes with undetected return values. For the specific process, please refer to the above content, which will not be repeated here. In the stage of generating data files for detection by the logic relationship detector, the embodiment of the present invention screens the generated data files to make the generated data files more concise, thereby fully simplifying the logic of the detection rules.

[0102] In an Ethereum smart contract return value unchecked verification method based on dynamic transaction information provided by an embodiment of the present invention: first, an Ethereum transaction transaction replay operation based on an Ethereum 2.0 or higher platform is performed and the operation code information of the replayed transaction transaction is recorded; secondly, the key logic of the operation code information is extracted and a transaction execution simulation process is performed, and the data information after the transaction simulation is collected; then, the required key operation code information is extracted from the data information, and converted into a data file that can be recognized by a logical relationship detector; finally, a logical relationship detector is constructed based on Datalog, and the constructed logical relationship detector and the pre-defined detection rules therein and the data file are used to detect whether the replayed transaction has a return value unchecked problem, so as to realize the marking of transactions with unchecked return values.

[0103] Since the embodiment of the present invention uses a logic rule detector constructed based on datalog, the construction of logic rules can be more free, so the constructed logic rules can be more targeted, and the detection rules formulated for the problem of undetected return values ​​are more concise, thereby fully simplifying the logic of the detection rules. Since the conciseness of the generated data file reduces the amount of data to be analyzed, the detection speed can be improved. In addition, during the operation code information extraction and analysis stage, the embodiment of the present invention considers more operation codes that may cause the problem of undetected return values, thereby expanding the detection range and improving the accuracy of detection due to the increase in the detection range.

[0104] Moreover, since the collection of opcode information in the embodiment of the present invention is based on the replay of executed transactions, there is no need to worry about the state space explosion problem. In addition, for transactions in which smart contracts call each other, the transaction can be tracked through the replay record of the transaction, thereby verifying whether there is a problem of undetected return value. Before the merger of Ethereum, users do not need to run a local execution layer client, but only need to use a server similar to Infura to access the Ethereum network; after the merger, users must run an execution layer client, and only when the execution layer client and the consensus layer client run together can they access the Ethereum network. The execution layer is responsible for processing transaction transactions and data, and the consensus layer is responsible for processing the POS consensus mechanism, so the consensus layer needs to be synchronized to detect the latest Ethereum transaction. Therefore, the embodiment of the present invention can be applied to the undetected return value verification of Ethereum smart contracts.

[0105] The static detection tool used in the prior art does not know the specific direction of each branch. Since valid transactions in Ethereum will be recorded in the block, and the embodiment of the present invention further analyzes the vulnerability by recording the specific bytecode generated by the transaction recorded in the EVM virtual machine execution block during the synchronization of the full node, as long as the transaction is recorded in the chain, the bytecode can be extracted for subsequent analysis, so the embodiment of the present invention belongs to the field of dynamic verification technology of smart contracts. The dynamic detection tool used in the embodiment of the present invention is based on the actual existing transactions during detection, so the specific direction of each branch is determined, so there will be no statement explosion problem. And the bytecode-level information collected by the dynamic detection tool does not care which contract the information comes from, so the call between contracts can also collect information normally. The verified transaction is a transaction that actually exists in reality, so the dynamic verification method is applied to detect whether there is a problem of undetected return value in the transaction that actually occurred, so that the corresponding parameters of each operation code when the smart contract is running are determined, and the execution of each branch is determined, so that the efficiency and accuracy of smart contract verification can be effectively guaranteed.

[0106] In the second aspect, corresponding to the above method embodiment, the embodiment of the present invention also provides an Ethereum smart contract return value untested verification device based on dynamic transaction information, such as Figure 3 As shown, the device comprises:

[0107] The transaction replay recording module 301 is used to perform the Ethereum transaction replay operation based on the Ethereum 2.0 platform and above and record the operation code information of the replayed transaction;

[0108] The simulated transaction execution module 302 is used to extract the key logic of the operation code information and perform the transaction execution simulation process, and collect the data information after the transaction simulation;

[0109] The key information extraction module 303 is used to extract the required key operation code information from the data information and convert it into a data file that can be recognized by the logic relationship detector;

[0110] The return value undetected verification module 304 is used to construct a logic relationship detector based on Datalog, and use the constructed logic relationship detector and the pre-defined detection rules and the data file to detect whether the replayed transaction has a return value undetected problem.

[0111] Furthermore, the transaction replay recording module 301 is specifically used for:

[0112] By synchronizing the nodes of the Ethereum network and modifying the source code of the Ethereum execution layer client in a preset manner, the executed transactions are replayed, and the operation code information of the replayed transactions is stored in the data set.

[0113] Further, the methods of synchronizing the nodes of the Ethereum network include:

[0114] The execution layer uses the full synchronization mode for synchronization, and the consensus layer uses the optimistic synchronization mode for synchronization.

[0115] Furthermore, the recorded replayed transaction operation code information includes:

[0116] The name of the opcode, the execution parameters of the opcode, and the location identification value of the opcode.

[0117] Furthermore, the simulated transaction execution module 302 is specifically used for:

[0118] Execute data dependency partitioning, including assigning unified specific parameters to data with dependencies according to the relative positions of the opcodes in the contract to achieve encoding of dependencies between data, and assigning an opcode location value to each opcode to distinguish data without dependencies; wherein the specific parameters include depth and number of calls;

[0119] According to the result after the data dependency partitioning process, the transaction execution simulation process is performed based on the stack operation of the simulated Ethereum virtual machine EVM, and the data information after the transaction simulation is collected.

[0120] Furthermore, the key information extraction module 303 is specifically used for:

[0121] According to different information types, extract the information of all key operation codes in the replay transaction from the data information to obtain key operation code information of various types; wherein the key operation codes include call, callcode, delegatecall and jumpi;

[0122] Each type of key operation code information is classified and stored in a data file.

[0123] Furthermore, the return value non-detection verification module 304, in the process of detecting whether the replayed transaction has the return value non-detection problem by using the constructed logical relationship detector and the detection rules pre-formulated therein and the data file, is specifically used to:

[0124] According to the usage record requirement of the parameter in the detection rule, the call, callcode and delegatecall operation codes in the data file are first screened to obtain a first result file;

[0125] Using the first result file, based on the requirements of the depth and the operation code location value in the detection rule, the call, callcode and delegatecall operation codes are matched with the jump operation code to obtain the information of the call, callcode and delegatecall operation codes with return value detection indicating successful matching, and store it in the second result file;

[0126] The first result file and the second result file are matched to obtain call, callcode and delegatecall opcodes without jumpi matching as opcodes with undetected return values, and information of these opcode calls is stored in the final result file.

[0127] Please refer to the relevant content of the first aspect for details and will not go into details here.

[0128] In a third aspect, an embodiment of the present invention further provides an electronic device, such as Figure 4 As shown, it includes a processor 401, a communication interface 402, a memory 403 and a communication bus 404, wherein the processor 401, the communication interface 402, and the memory 403 communicate with each other through the communication bus 404;

[0129] The memory is used to store computer programs;

[0130] The processor is used to implement the steps of any one of the Ethereum smart contract return value untested verification methods based on dynamic transaction information provided in the first aspect of the embodiment of the present invention when executing the program stored in the memory.

[0131] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0132] The communication interface is used for communication between the above electronic device and other devices.

[0133] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0134] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0135] The method provided in the embodiment of the present invention can be applied to electronic devices. Specifically, the electronic device can be: a desktop computer, a portable computer, an intelligent mobile terminal, a server, etc. This is not limited here, and any electronic device that can implement the present invention belongs to the protection scope of the present invention.

[0136] In the fourth aspect, corresponding to the Ethereum smart contract return value untested verification method based on dynamic transaction information provided in the first aspect, an embodiment of the present invention further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by the processor, it implements any step of the Ethereum smart contract return value untested verification method based on dynamic transaction information provided in the first aspect of the embodiment of the present invention.

[0137] As for the device / electronic device / storage medium embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0138] It should be noted that the device, electronic device and storage medium of the embodiments of the present invention are respectively the device, electronic device and storage medium to which the above-mentioned Ethereum smart contract return value untested verification method based on dynamic transaction information is applied. All embodiments of the above-mentioned Ethereum smart contract return value untested verification method based on dynamic transaction information are applicable to the device, electronic device and storage medium, and can achieve the same or similar beneficial effects.

[0139] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0140] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A method for verifying the return value of an Ethereum smart contract based on dynamic transaction information, characterized in that: include: Execute Ethereum transaction replay operations based on Ethereum 2.0 and above platforms and record the operation code information of the replayed transaction; Extract the key logic of the operation code information and simulate the transaction execution process, and collect the data information after the transaction simulation; Extracting the required key operation code information from the data information and converting it into a data file that can be recognized by the logic relationship detector; A logic relationship detector is constructed based on Datalog, and the constructed logic relationship detector and the detection rules pre-defined therein and the data file are used to detect whether the replayed transaction has a return value undetected problem; The step of extracting the required key operation code information from the data information and converting it into a data file that can be recognized by the logic relationship detector includes: According to different information types, extract the information of all key operation codes in the replay transaction from the data information to obtain key operation code information of various types; wherein the key operation codes include call, callcode, delegatecall and jumpi; Classify and store each type of key operation code information into data files; The method of using the constructed logical relationship detector, the detection rules pre-defined therein, and the data file to detect whether the replayed transaction has a return value undetected problem includes: According to the usage record requirement of the parameter in the detection rule, the call, callcode and delegatecall operation codes in the data file are first screened to obtain a first result file; Using the first result file, based on the requirements of the depth and the operation code location value in the detection rule, the call, callcode and delegatecall operation codes are matched with the jump operation code to obtain the information of the call, callcode and delegatecall operation codes with return value detection indicating successful matching, and store it in the second result file; The first result file and the second result file are matched to obtain call, callcode and delegatecall opcodes without jumpi matching as opcodes with undetected return values, and information of these opcode calls is stored in the final result file.

2. The Ethereum smart contract return value unmeasured verification method based on dynamic transaction information according to claim 1 is characterized in that: The execution of the Ethereum transaction replay operation based on the Ethereum 2.0 or higher platform and recording the operation code information of the replayed transaction includes: By synchronizing the nodes of the Ethereum network and modifying the source code of the Ethereum execution layer client in a preset manner, the executed transactions are replayed, and the operation code information of the replayed transactions is stored in the data set.

3. The Ethereum smart contract return value unmeasured verification method based on dynamic transaction information according to claim 2 is characterized in that: Ways to synchronize nodes on the Ethereum network include: The execution layer uses the full synchronization mode for synchronization, and the consensus layer uses the optimistic synchronization mode for synchronization.

4. The Ethereum smart contract return value unmeasured verification method based on dynamic transaction information according to claim 1 is characterized in that: The recorded replayed transaction operation code information includes: The name of the opcode, the execution parameters of the opcode, and the location identification value of the opcode.

5. The Ethereum smart contract return value verification method based on dynamic transaction information according to any one of claims 1 to 4, characterized in that: The key logic of extracting the operation code information and performing the transaction execution simulation process, and collecting the data information after the transaction simulation, include: Execute data dependency partitioning, including assigning unified specific parameters to data with dependencies according to the relative positions of the opcodes in the contract to achieve encoding of dependencies between data, and assigning an opcode location value to each opcode to distinguish data without dependencies; wherein the specific parameters include depth and number of calls; According to the result after the data dependency partitioning process, the transaction execution simulation process is performed based on the stack operation of the simulated Ethereum virtual machine EVM, and the data information after the transaction simulation is collected.

6. An Ethereum smart contract return value unchecked verification device based on dynamic transaction information, characterized in that: include: The transaction replay recording module is used to perform Ethereum transaction replay operations based on Ethereum 2.0 and above platforms and record the operation code information of the replayed transaction; The simulated transaction execution module is used to extract the key logic of the operation code information and perform the transaction execution simulation process, and collect the data information after the transaction simulation; A key information extraction module, used to extract the required key operation code information from the data information and convert it into a data file that can be recognized by the logic relationship detector; The return value non-detection verification module is used to construct a logic relationship detector based on Datalog, and use the constructed logic relationship detector and the pre-defined detection rules and the data file therein to detect whether the replayed transaction has a return value non-detection problem; The key information extraction module extracts the required key operation code information from the data information and converts it into a data file that can be recognized by the logic relationship detector, specifically for: According to different information types, extract the information of all key operation codes in the replay transaction from the data information to obtain key operation code information of various types; wherein the key operation codes include call, callcode, delegatecall and jumpi; Classify and store each type of key operation code information into data files; The return value undetected verification module uses the constructed logical relationship detector and the pre-defined detection rules and the data file to detect whether the replayed transaction has the return value undetected problem, specifically for: According to the usage record requirement of the parameter in the detection rule, the call, callcode and delegatecall operation codes in the data file are first screened to obtain a first result file; Using the first result file, based on the requirements of the depth and the operation code location value in the detection rule, the call, callcode and delegatecall operation codes are matched with the jump operation code to obtain the information of the call, callcode and delegatecall operation codes with return value detection indicating successful matching, and store it in the second result file; The first result file and the second result file are matched to obtain call, callcode and delegatecall opcodes without jumpi matching as opcodes with undetected return values, and information of these opcode calls is stored in the final result file.

7. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; The memory is used to store computer programs; The processor is used to implement the method steps described in any one of claims 1-5 when executing the program stored in the memory.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps described in any one of claims 1 to 5 are implemented.

Images