Defect detection method and device for ethereum smart contract transaction based on no gil parallelism

Abstract

The application discloses a kind of based on No GIL parallel's Ethereum smart contract transaction defect detection method and device, the method provided in the application based on No GIL parallel's Ethereum smart contract transaction defect detection method: replay transaction using Ethereum virtual machine, collect the tracking data of bytecode level in transaction process;According to the interdependence of tracking data, divide tracking data, to simulate EVM stack and build transaction processing graph;Based on No GIL, transaction processing graph is processed, and intermediate representation information is constructed, to obtain data file;Data file is detected using preset detection rule, and then whether there is hidden danger of being attacked in transaction process is detected.Due to the embodiment of the application, the efficiency of transaction processing graph construction and conversion part which is most likely to time out is greatly improved, and the time of attack detection is shortened.

Description

Technical Field

[0001] This invention belongs to the field of smart contract dynamic detection technology, specifically relating to a method and device for detecting defects in Ethereum smart contract transactions based on No GIL parallelism. Background Technology

[0002] A smart contract is a stateful, event-driven program that runs on a blockchain system. Currently, there are over 50 million smart contracts on Ethereum alone. At the same time, attacks targeting smart contracts are increasing. Smart contracts, which control large amounts of funds on the blockchain, inevitably have security vulnerabilities caused by program flaws, and because they manage a large amount of digital token assets, attackers can gain enormous profits by attacking them.

[0003] Due to the unique operating environment, complexity, and rapid development of blockchain technology, smart contract vulnerability detection has always been a challenge. Currently, an increasing number of detection tools are being proposed. The main problems and shortcomings of existing technologies are as follows:

[0004] (1) Most existing vulnerability detection tools are static detection tools, which can only analyze the code provided to them and cannot combine it with context. Therefore, external factors affecting smart contract behavior and vulnerabilities in specific use cases cannot be detected. Symbolic execution-based tools encounter the path explosion problem and cannot detect vulnerabilities involving multiple smart contracts. These tools generally have problems such as limited detection scope and false negatives / false negatives.

[0005] (2) Existing vulnerability detection tools often encounter timeouts and other problems when performing bytecode analysis on transactions due to the complexity and large number of certain special bytes, which affects the overall detection efficiency.

[0006] (3) After the Ethereum platform was upgraded, the consensus mechanism and node synchronization mechanism changed, and many detection tools were not yet adapted to the new platform and were difficult to detect.

[0007] Therefore, existing technologies need to be improved. Summary of the Invention

[0008] To address the aforementioned problems in existing technologies, this invention provides a method for detecting transaction defects in Ethereum smart contracts based on No GIL parallelism. The technical problem to be solved by this invention is achieved through the following technical solution:

[0009] In a first aspect, embodiments of the present invention provide a method for detecting defects in Ethereum smart contract transactions based on No GIL parallelism, including:

[0010] By replaying transactions using the Ethereum Virtual Machine, bytecode-level tracking data can be collected during the transaction process.

[0011] The tracking data is divided according to the dependencies between the tracking data to simulate the transaction processing graph of the EVM stack;

[0012] Based on No GIL, the transaction processing graph is processed to construct intermediate representation information and obtain a data file;

[0013] The data file is tested using preset detection rules to detect potential attacks during the transaction process.

[0014] The tracking data includes multiple bytecode data, each of which includes a program counter, an opcode, and the parameter value of the opcode.

[0015] Specifically, the tracking data is divided according to the dependencies between the tracking data to simulate the transaction processing graph of the EVM stack, including:

[0016] Determine the bytecode data to be processed based on the dependencies of the tracking data;

[0017] The bytecode data to be processed is simulated to obtain simulated data information;

[0018] The transaction processing diagram is obtained based on the simulated data.

[0019] The step of determining the bytecode data to be processed based on the dependencies of the tracking data includes:

[0020] Each byte of data in the tracking data is assigned a corresponding opcode location value; the location value is different for each data.

[0021] The dependencies between bytecode data are determined based on the opcode location value, and the bytecode data with dependencies are taken as bytecode data to be processed.

[0022] The bytecode data to be processed is simulated to obtain simulated data information, including:

[0023] The Ethereum Virtual Machine is used to simulate the processing of the bytecode data to be processed, thereby obtaining simulated data information.

[0024] Specifically, based on the No GIL method, the transaction processing graph is processed to construct intermediate representation information, resulting in a data file, including:

[0025] The opcode sequence is transformed into a first instruction block and a second instruction block; wherein, the opcode sequence consists of opcodes of bytecode data to be processed in the transaction processing graph; the instructions in the first instruction block represent the execution flow changing from one smart contract to another, and the second instruction block includes contract call instructions;

[0026] Based on the No GIL tool, the first instruction block is processed in a multi-threaded parallel manner, and the second instruction block is processed in a serial manner, thereby obtaining intermediate representation information;

[0027] Parameter data is extracted from the intermediate representation information to obtain a data file, wherein each opcode has a data file arranged in order of depth, and the data file includes a program counter, registers, opcode location value, call depth, and call count.

[0028] The data file is inspected using preset detection rules to detect potential vulnerabilities in the transaction process, including:

[0029] Each data file is tested using preset detection rules to determine whether there are any potential vulnerabilities to attacks at various call depths.

[0030] If there is a risk of attack, the opcode corresponding to the data file will be recorded as the result file.

[0031] This involves using preset detection rules to inspect each data file to determine whether there are any vulnerabilities to attacks at various call depths, including:

[0032] The opcodes are classified based on the data file to obtain a first opcode set, a second opcode set, and a third opcode set; the first opcode set includes contract invocation instructions, the second opcode set includes contract invocation instructions and retains the caller, and the third opcode set includes delegated invocation instructions;

[0033] Each opcode in the first, second, and third opcode sets is matched with the jump instruction opcode. If there is a mismatched opcode, there is a risk of being attacked.

[0034] The step of matching each opcode in the first opcode set, the second opcode set, and the third opcode set with the jump instruction opcode includes:

[0035] If the position value of the opcode in the first opcode set, the second opcode set, and the third opcode set is smaller than the position value of the jump instruction opcode, then the opcode mismatch is determined.

[0036] Thirdly, embodiments of the present invention provide 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;

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

[0038] When the processor executes the program stored in the memory, it implements the steps of the transaction defect detection method provided in the embodiments of the present invention.

[0039] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the transaction defect detection method provided in the embodiments of the present invention.

[0040] The beneficial effects of this invention are:

[0041] This invention provides a No-GIL-based parallel Ethereum smart contract transaction defect detection method: Transactions are replayed using the Ethereum Virtual Machine (EVM) to collect bytecode-level tracking data during the transaction process; the tracking data is divided according to dependencies to simulate the EVM stack and construct a transaction processing graph; the transaction processing graph is processed based on No-GIL to construct intermediate representation information, resulting in a data file; and the data file is tested using preset detection rules to detect potential attack vulnerabilities during the transaction process. Because this invention uses a No-GIL-based parallel method to parse bytecode, the efficiency of the transaction processing graph construction and conversion parts, which are most prone to timeouts, is greatly improved, shortening the attack detection time. Attached Figure Description

[0042] Figure 1 This is a flowchart illustrating a method for detecting Ethereum smart contract transaction defects based on No GIL parallelism, as provided in an embodiment of the present invention.

[0043] Figure 2 for Figure 1 A flowchart of the S2 process;

[0044] Figure 3 for Figure 1 A flowchart of the S3 process;

[0045] Figure 4 for Figure 1 A flowchart of the S4 process;

[0046] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0047] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] like Figure 1 As shown, a flowchart of an embodiment of the Ethereum smart contract transaction defect detection method based on No GIL parallelism provided by this invention is illustrated, including the following steps S1 to S4:

[0049] S1: Replay transactions using the Ethereum Virtual Machine to collect bytecode-level tracking data during the transaction process.

[0050] Specifically, during the execution of Ethereum transactions within the Ethereum Virtual Machine (EVM), records at the bytecode level are collected. Each bytecode-level record is a sequence of 3-tuples. For each bytecode executed by the EVM, each bytecode data includes a program counter, an opcode, and the opcode's parameter value. We record its program counter (PC), opcode (OPCODE), and opcode parameter value (ARGS) within the EVM as a 3-tuple, i.e., { <pc> ； <opcode> ； <args>It should be noted that opcodes are the instruction set of the EVM, which define the operations required to execute smart contracts.

[0051] In one embodiment, to obtain bytecode-level information during transaction processing, it is necessary to synchronize Ethereum network nodes and modify the Ethereum client source code to replay the already executed transactions in order to extract transaction records and store them in the Trace Database along with relevant metadata.

[0052] Ethereum completed its merger on September 15, 2022, upgrading to Ethereum 2.0. The consensus mechanism shifted from Proof of Work (PoW) to Proof of Stake (PoS), and the synchronization mechanism for nodes also changed. Before the merger, users did not need to run a local execution client; they could simply run an execution client for synchronization and access the Ethereum network using servers similar to Infura. After the merger, users must run an execution layer client. Only when both the execution layer client and the consensus layer client are running can users access the Ethereum network. The execution layer handles transactions and data, while the consensus layer handles the PoS consensus mechanism. Regarding the choice of execution and consensus clients, based on Ethereum's Client Diversity statistics on client usage, we chose to run the Prysm consensus layer client and the Go-Ethereum execution layer client, employing a full-node synchronization strategy. This involves downloading the complete blockchain data from the genesis block and replaying the transactions in the execution blocks. This method provides the highest level of security and data integrity. To obtain complete transaction opcode information, we use full synchronization mode at the execution layer and optimistic synchronization at the consensus layer.

[0053] Meanwhile, to facilitate centralized collection and processing of bytecode-level records, the source code of the Go-Ethereum client was modified to add a Mongo database module to extract transaction records and store them in the Trace Database along with related metadata.

[0054] S2: Divide the tracking data according to the dependencies between the tracking data to simulate the transaction processing graph of the EVM stack.

[0055] In S1, we extracted the tracking data. The bytecode-level data in the tracking data cannot be directly used to detect transaction defects such as undetected return values ​​using pre-defined rules. Therefore, we need to further transform the extracted dataset.

[0056] In one alternative implementation, please refer to Figure 2 S2 includes the following steps:

[0057] S21: Determine the bytecode data to be processed based on the dependencies of the trace data.

[0058] Specifically, each bytecode data in the traced data is assigned a corresponding opcode location value; each data point has a different location value; based on the opcode location values, the dependencies between bytecode data are determined, and bytecode data with dependencies are treated as bytecode data to be processed. Specifically, to distinguish data without dependencies, we need to assign an opcode location value `loc` to each bytecode data; the location value for each bytecode data is different, and data with dependencies are placed in the same block.

[0059] S22: Simulate the bytecode data to be processed to obtain simulated data information.

[0060] The Ethereum Virtual Machine (EVM) is used to simulate the processing of bytecode data to obtain simulated data information. Specifically, based on the data dependency partitioning and processing results, the bytecode data to be processed is simulated using the stack operations of the simulated EVM to collect simulated transaction data information.

[0061] The transaction execution simulation process uses data dependency partitioning to obtain further opcode information. This opcode information needs to be further analyzed by simulating the Ethereum Virtual Machine (EVM) stack operations. For some opcodes, whose execution parameters are known during the information gathering phase, these parameters are collected and pushed onto the stack. For others, such as Jumpi and Mstore, whose execution parameters are not available during the information gathering phase, a pop operation is performed during stack simulation; the data popped from the stack represents the opcode's execution parameters. This step is to obtain more complete data information, as subsequent analysis requires the execution parameters of all opcodes to determine more nuanced relationships between them.

[0062] Step S23: Obtain the transaction processing diagram based on the simulated data information.

[0063] The transaction processing diagram includes all bytecode-level traces collected after transaction replay, including a large number of opcodes. For opcodes such as Jumpi and Mstore, their parameters are determined after transaction execution. Therefore, for bytecode-level traces, we need to simulate the EVM stack operations for further analysis to obtain the real values ​​corresponding to the opcode execution, and number the stack opcodes for logical relationship analysis.

[0064] To record crucial information throughout the entire transaction execution process, a Transaction Processing Graph (TPC) was constructed based on the execution order of smart contracts. Each node in the TPC represents the execution of a smart contract, containing the bytecode-level execution trajectory generated by that smart contract. Each edge in the TPC represents the control flow transfer from one smart contract to another. Nodes and edges are dynamically generated. During bytecode-level tracing, a new node is generated when encountering CALL or STOP opcodes. When the execution flow transfers from one smart contract to another, the execution flow graph generator generates edges representing the control flow between the two nodes. By simulating the EVM stack based on the smart contract execution order, a transaction processing graph can be constructed. This graph contains information such as (PC, OPCODE, ARGS, Idx, Depth, Callnum) for the transaction, and the stack opcodes are also numbered for subsequent extraction and analysis of logical relationships.

[0065] S3: Process the transaction processing graph based on No GIL (No Global Interpreter Lock) to construct intermediate representation information and obtain the data file.

[0066] In one alternative implementation, please refer to Figure 3 S3 includes the following steps:

[0067] S31: Transform the opcode sequence into a first instruction block and a second instruction block. The opcode sequence consists of opcodes of the bytecode data to be processed in the transaction processing diagram.

[0068] Specifically, each basic block of the transaction processing graph is divided into two categories based on the different opcodes in its first line, which facilitates subsequent parsing.

[0069] Specifically, in S2, a transaction processing graph has been generated, and the tracked opcode sequence is converted into two basic block types: evm_block and evm_block. The first block contains an opcode starting with 0PUSH1 (first instruction block), and the second block contains an instruction starting with a special character such as CALL (second instruction block). The instructions in the first instruction block represent a change in execution flow from one smart contract to another, while the second instruction block includes contract call instructions. In one embodiment, the second instruction block represents the case where an opcode related to CALL is encountered, resulting in the generation of a new node. Separating these two types of basic blocks facilitates subsequent parallel processing.

[0070] S32: Based on the No GIL tool, the first instruction block is processed in a multi-threaded parallel manner, and the second instruction block is processed in a serial manner, thereby obtaining intermediate representation information.

[0071] In the logic relation generator, we need to parse the transaction processing graph to construct intermediate representation information (IR) suitable for analysis, that is, convert the EVM opcode sequence into register transfer language. This step refers to the rules of IR representation in vandal, but with extensions and improvements. First, real values, rather than symbolic values, need to be processed. In the logic relation generator, this is achieved by simulating EVM stack operations using registers with real values, so that the register values ​​are updated accordingly, and all intermediate values ​​are correctly recorded. This is a crucial step in capturing all dynamic information during transaction execution, which static analysis tools cannot achieve. For example, when processing timestamps, the real timestamp value recorded in the bytecode-level trace is pushed onto the stack and assigned to its associated register. Second, inter-contract calls need to be processed. Inter-contract calls are categorized into two types of edges in TPC: for type I edges in TPC, the current stack is sealed, and an empty stack is created. For type II edges in TPC, the current stack is deleted, and the last sealed stack is restored. Third, the naming of the register was changed. It is usually numbered according to the order of all recorded opcodes as "V + sequence number". It was changed to "block number + V + intra-block sequence number", which broke the inter-block relationship to facilitate parallel processing later. At the same time, it also avoids the large number of register numbers, such as hundreds of thousands, due to too much transaction information.

[0072] To improve parsing speed, we use the No GIL tool to process blocks starting with 0PUSH1 (i.e., the first instruction block) in a multi-threaded manner.

[0073] Specifically, due to the characteristics of the CPython interpreter, the Global Interpreter Lock (GIL) restricts only one thread to run at a time. Even with multithreading, it's essentially single-core processing, equivalent to serial execution, which doesn't improve efficiency. We used the NoGIL tool to achieve parallelism, creating multiple threads to convert the 0PUSH1 block into basic blocks represented in IR language in parallel, and storing the stack generated during the parsing of each block into the overall list stacks according to the block number.

[0074] For blocks beginning with special opcodes such as CALL (i.e., the second instruction block), because the parsing process calls the stack of the previous block, it does not meet the conditions for parallel conversion. Therefore, the second instruction block is processed serially, and the required stack is retrieved from the stacks when necessary according to the conversion rules. Finally, the transaction processing graph is converted into IR form.

[0075] S33: Extract parameter data from the intermediate representation information to obtain a data file. Each opcode has a data file arranged in order of depth. The data file includes the program counter, registers, opcode location value, call depth, and call count.

[0076] For successfully converted intermediate representation information (IR), parameter data is extracted from the intermediate representation information according to the detection rules to obtain a data file. The data file includes the program counter (PC), register (Register), opcode location value (Idx), call depth (Depth), and call count (Callnum), denoted as (PC, Register, Idx, Depth, Callnum). Parallel extraction is used for calls at different depths to improve efficiency; that is, each opcode has its own data file sorted by depth from smallest to largest.

[0077] S4: Use preset detection rules to detect data files, thereby detecting potential attacks during the transaction process.

[0078] Specifically, an attack detector is built based on the Datalog language, and the built attack detector and preset detection rules are used to detect data files (facts files), thereby detecting whether there are potential attacks during the transaction process.

[0079] At different depths, multi-threading technology is used to detect potential attacks in transactions in parallel.

[0080] S4 requires pre-defined attack detection rules and the construction of an attack detector based on a specific Datalog language. The detector then inspects data files to determine if any vulnerabilities exist during transactions. If a vulnerability is found, the corresponding opcodes in the data file are recorded as the result file.

[0081] The attack detector, built on a specific Datalog, comprises an open-source Datalog engine and detection rules tailored to various transaction attacks. The open-source Datalog engine includes an interpreter and a compiler to execute Datalog programs, while the detection rules are Datalog programs written based on collected information and required functionalities, including handling different depth-based calls. The attack detector performs parallel checks on extracted critical opcode information according to the defined detection rules, determining whether the transaction is vulnerable at various depths. If a vulnerability is found, the corresponding opcode information is recorded in the final results file. Unlike the serial detection rules in typical attack detectors, S4 improves the parallelization of detection for calls at different depths within a transaction, significantly increasing the efficiency of attack detection and enhancing specific transaction security.

[0082] Taking the handling process of the unchecked return value problem as an example, the unchecked return value refers to a situation where a transaction uses the contract call instruction (Call) or retains the caller's callcode or delegate call instruction (Delegatecall) opcode during execution, but after use, it does not check whether the return value meets expectations, that is, there is no corresponding Jumpi operation, and no relevant handling measures are taken.

[0083] In one optional implementation, S4 specifically includes:

[0084] S41: Classify the opcodes based on the data file to obtain a first opcode set, a second opcode set, and a third opcode set.

[0085] The first set of opcodes includes the contract call instruction Call, the second set of opcodes includes the contract call instruction and retains the caller's Callcode, and the third set of opcodes includes the delegate call instruction Delegatecall.

[0086] According to the parameter usage requirements in the detection rules, the Call (contract call instruction), Callcode (contract call instruction with caller information retained), and Delegatecall (delegation call instruction) opcodes in the data file need to be filtered to obtain a filtered result file. Specifically, when the detection rules are formulated, the Call, Callcode, and Delegatecall opcodes are conditionally filtered to determine whether there are any matching return value detection opcodes for each opcode. Only Call, Callcode, and Delegatecall opcodes that meet the conditions will be matched and detected to correspond with Jumpi opcodes.

[0087] 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 the same depth can be matched. In other words, matching opcodes must have the same depth parameter.

[0088] In one embodiment, if the position value of an opcode in the first, second, and third opcode sets is greater than the position value of a jump instruction opcode, then the opcode is determined to correspond to a Jumpi opcode, thus meeting the condition. If the position value of an opcode in the first, second, and third opcode sets is smaller than the position value of a jump instruction opcode, then the opcode is determined not to correspond to a Jumpi opcode, thus failing the condition and resulting in a mismatch.

[0089] During the detection process, the filtering criterion is that a parameter involved in these calls must be recorded in another opcode data file used to record parameter usage. If the position value of the opcode in the first, second, and third opcode sets is greater than the position value of the jump instruction opcode, then the opcode is determined to correspond to a Jumpi opcode and meets the condition. Information meeting the condition is used as the filtered information and stored in a filtered result file, which can be named "filtered_res".

[0090] S42: Match each opcode in the first opcode set, the second opcode set, and the third opcode set with the jump instruction opcode. If there is a mismatched opcode, there is a risk of being attacked.

[0091] If the position value of the opcode in the first opcode set, the second opcode set, and the third opcode set is smaller than the position value of the jump instruction opcode, then the opcode mismatch is determined.

[0092] Unlike the general approach that only checks the first-level deep call for undetected return values, this invention utilizes a preprocessed result file and, based on the depth and opcode location requirements in the attack detection rules, performs parallel matching value judgments between the Call, Callcode, and Delegatecall opcodes and the Jumpi opcode at different depths. The information indicating that a successful match has been found and that a return value has been detected is stored in the matching result file.

[0093] In this step, for Call, Callcode, and Delegatecall opcodes and Jumpi opcodes, the matching opcodes must have the same depth parameter. Therefore, efficiency can be improved by parallelizing each pair of opcodes at different depths.

[0094] The opcode information of a successful match is stored in the match result file, which can be named "matched_res".

[0095] The filtered result file and the matching result file are matched again to obtain Call, Callcode, and Delegatecall opcodes that do not match with Jumpi. These are considered opcodes with return values ​​that have not been checked, and the information of these opcode calls is stored in the final result file.

[0096] If the opcodes Call, Callcode, and Delegatecall that are not matched by Jumpi are obtained through S42, it indicates that the transaction has an unchecked return value problem, that is, the opcodes are mismatched, which poses a risk of attack.

[0097] This invention provides a method for detecting defects in Ethereum smart contract transactions based on No GIL parallelism: First, Ethereum transactions based on Ethereum 2.0 are replayed and bytecode-level tracing is recorded; second, data dependencies are encoded to simulate the EVM stack and construct a transaction processing graph; then, the transaction processing graph is parsed in parallel to construct intermediate representation information (IR), and the required information is extracted to generate a data file; finally, an attack detector based on Datalog is constructed, and attacks in transactions are detected in parallel at different depths using the attack detector and predefined rules, thereby achieving attack detection on smart contract transactions.

[0098] Because this invention uses a parallel method based on the No GIL to parse bytecode, the efficiency of the transaction processing graph construction and transformation, which is most prone to timeouts, is greatly improved, shortening the attack detection time. We also used parallel methods to improve efficiency in the extraction of key information and rule-based detection processes. Furthermore, for cases where return values ​​were not detected, we extracted key opcode information at different depths, thereby expanding the detection scope and improving detection accuracy.

[0099] Furthermore, since our improvements to the bytecode parsing part are universal, they will improve all defect detection tools based on bytecode execution. Also, by utilizing No GIL to avoid the limitations of the CPython interpreter's global interpretation lock on computationally intensive tasks, we have expanded the scope of our parallel bytecode parsing framework migration to more areas.

[0100] Meanwhile, since the embodiments of this invention belong to the field of smart contract dynamic detection technology, and the verified transactions are real transactions that actually exist, applying the dynamic verification method to detect whether there is a problem of undetected return values ​​in real transactions ensures that the corresponding parameters of each opcode during smart contract execution are determined, and the execution status of each branch is determined, thus effectively guaranteeing the efficiency and accuracy of smart contract verification.

[0101] Thirdly, embodiments of the present invention also provide an electronic device, such as... Figure 5 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.

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

[0103] When the processor executes the program stored in the memory, it implements any of the method-based steps provided in the first aspect of the present invention.

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

[0105] The communication interface is used for communication between the aforementioned electronic devices and other devices.

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

[0107] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0108] The method provided in this invention can be applied to electronic devices. Specifically, the electronic device can be a desktop computer, a portable computer, a smart mobile terminal, a server, etc. No limitation is made herein; any electronic device that can implement this invention falls within the protection scope of this invention.

[0109] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the Ethereum smart contract transaction defect detection methods based on No GIL parallelism provided in the first aspect of this invention.

[0110] For the embodiments of the device / electronic device / storage medium, since they are basically similar to the method embodiments, the description is relatively simple, and relevant parts can be referred to in the description of the method embodiments.

[0111] It should be noted that the electronic device and storage medium of the present invention can implement all the above-described methods and embodiments, and can achieve the same or similar beneficial effects.

[0112] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0113] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.< / args> < / opcode> < / pc>

Claims

1. A method for detecting transaction defects in Ethereum smart contracts based on No GIL parallelism, characterized in that, include: By replaying transactions using the Ethereum Virtual Machine, bytecode-level tracking data can be collected during the transaction process. The tracking data is divided according to the dependencies between the tracking data to simulate the transaction processing graph of the EVM stack; Based on No GIL, the transaction processing graph is processed to construct intermediate representation information and obtain a data file; The data file is tested using preset detection rules to detect potential attacks during the transaction process. Specifically, the tracking data is divided according to the dependencies between the tracking data to simulate the transaction processing graph of the EVM stack, including: Each byte of data in the tracking data is assigned a corresponding opcode location value; the location value is different for each data. The dependencies between bytecode data are determined based on the opcode location values, and the bytecode data with dependencies are taken as bytecode data to be processed. The Ethereum Virtual Machine is used to simulate the processing of the bytecode data to be processed, thereby obtaining simulated data information; The transaction processing diagram is obtained based on the simulated data information; Specifically, based on the No GIL method, the transaction processing graph is processed to construct intermediate representation information, resulting in a data file, including: The opcode sequence is transformed into a first instruction block and a second instruction block; wherein, the opcode sequence consists of opcodes of bytecode data to be processed in the transaction processing graph; the instructions in the first instruction block represent the execution flow changing from one smart contract to another, and the second instruction block includes contract call instructions; Based on the No GIL tool, the first instruction block is processed in a multi-threaded parallel manner, and the second instruction block is processed in a serial manner, thereby obtaining intermediate representation information; Parameter data is extracted from the intermediate representation information to obtain a data file, wherein each opcode has a data file arranged in order of depth, and the data file includes a program counter, registers, opcode location value, call depth, and call count.

2. The method according to claim 1, characterized in that, The tracking data includes multiple bytecode data, each of which includes a program counter, an opcode, and the parameter value of the opcode.

3. The method according to claim 1, characterized in that, The data file is inspected using preset detection rules to detect potential vulnerabilities in the transaction process, including: Each data file is tested using preset detection rules to determine whether there are any potential vulnerabilities to attacks at various call depths. If there is a risk of attack, the opcode corresponding to the data file will be recorded as the result file.

4. The method according to claim 3, characterized in that, Each data file is inspected using preset detection rules to determine whether there are any vulnerabilities to attacks at various call depths, including: The opcodes are classified based on the data file to obtain a first opcode set, a second opcode set, and a third opcode set; the first opcode set includes contract invocation instructions, the second opcode set includes contract invocation instructions and retains the caller, and the third opcode set includes delegated invocation instructions; Each opcode in the first, second, and third opcode sets is matched with the jump instruction opcode. If there is a mismatched opcode, there is a risk of being attacked.

5. The method according to claim 4, characterized in that, The step of matching each opcode in the first opcode set, the second opcode set, and the third opcode set with the jump instruction opcode includes: If the position value of the opcode in the first opcode set, the second opcode set, and the third opcode set is smaller than the position value of the jump instruction opcode, then the opcode mismatch is determined.

6. 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; When the processor executes the program stored in the memory, it implements the steps of the method described in any one of claims 1-5.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-5.

Images