Data extraction method and device, server, and storage medium

Abstract

The application provides a data extraction method and device, a server and a storage medium. In the method, at least one block of an Ethereum transaction is pulled, the block includes multiple transactions, and a record identifier of a target operation code is added in an Ethereum virtual machine. Then, based on the record identifier of the target operation code, the multiple transactions in the at least one block are executed by using the Ethereum virtual machine to obtain an execution result of the at least one block. In the technical solution, the data related to the record target operation code is recorded from the configured Ethereum virtual machine, that is, the operation code related to the block chain or the transaction, the operation code related to the memory or the storage, and the push operation code. The Ethereum virtual machine extracts the specific operation and the state variable with the record smart contract interface call in the Ethereum transaction, and collects the basic state of the transaction, so as to provide basic data for smart contract analysis and vulnerability analysis.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data extraction method, apparatus, server, and storage medium. Background Technology

[0002] Ethereum is one of the larger public decentralized computing platforms built on blockchain technology. It provides Turing-complete computing functions in the form of smart contracts. Currently, when it is necessary to perform subsequent summarization and other related processing on Ethereum transaction information, Ethereum transaction information is often obtained in advance.

[0003] Currently, the common method for obtaining this information is to pull all Ethereum blocks and analyze the transactions by parsing the transaction content of the blocks. This method can obtain the input content of the transaction (transaction initiation address, transaction receiving address, smart contract interface call, etc.) and the transaction execution result (account balance, transaction execution result).

[0004] The above technical solution cannot obtain the specific operations and state variables of smart contract interface calls during the transaction, and cannot provide data support for more accurate analysis of the issues involved in the transaction in the subsequent processing of transaction information. Summary of the Invention

[0005] In view of this, this application provides a data extraction method, apparatus, server, and storage medium for obtaining the specific operations and state variables of smart contract interface calls in transactions, thereby providing data support for solutions to potential problems in subsequent transaction information processing.

[0006] The first aspect of this application provides a data extraction method, the method comprising:

[0007] Fetch at least one block of Ethereum transactions, the block comprising multiple transactions;

[0008] Add a record identifier for the target opcode in the Ethereum Virtual Machine. The target opcode is the opcode corresponding to the specific operation and state variable of the smart contract interface call.

[0009] Based on the record identifier of the target opcode, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block to obtain the execution result of the at least one block. The execution result is the specific operation and state variables of the smart contract interface call when executing the multiple transactions.

[0010] In one possible design of the first aspect, the target opcode includes: an opcode related to a blockchain or transaction;

[0011] Accordingly, the step of using the Ethereum Virtual Machine to execute the multiple transactions in the at least one block based on the record identifier of the target opcode to obtain the execution result of the at least one block includes:

[0012] Based on the opcodes related to the blockchain or transactions, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block, and the first data corresponding to the opcodes related to the blockchain or transactions is recorded during the execution process;

[0013] The first data is used as the state variable, and the execution result is the specific operation of the smart contract interface call and the first data when executing the multiple transactions.

[0014] In another possible design of the first aspect, the target opcode further includes: an opcode related to memory or storage, and a push opcode;

[0015] Accordingly, the step of using the Ethereum Virtual Machine to execute the multiple transactions in the at least one block based on the record identifier of the target opcode to obtain the execution result of the at least one block includes:

[0016] Based on the memory- or storage-related opcodes and the push opcodes, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block, and during the execution process, the second data corresponding to the memory- or storage-related opcodes and the third data corresponding to the push opcodes are recorded;

[0017] The second data and the third data are used as the specific operation, and the execution result is the second data, the third data, and the state variable called by the smart contract interface when executing the multiple transactions.

[0018] In another possible design of the first aspect, after executing the plurality of transactions in the at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode to obtain the execution result of the at least one block, the method further includes:

[0019] Store the execution results of the at least one block.

[0020] In this possible design, storing the execution result of the at least one block includes:

[0021] Based on the execution result of at least one block, generate a log;

[0022] The logs are stored in the database.

[0023] In another possible design in the first aspect, the fetching of at least one block of Ethereum transactions includes:

[0024] Obtain a list of blockchains from the nodes of the blockchain of the Ethereum transaction, the list of blockchains including the identifier of the at least one block;

[0025] The at least one block is retrieved from the blockchain based on the identifier of the at least one block.

[0026] A second aspect of this application provides a data extraction apparatus, which includes: an acquisition module, an addition module, and a processing module;

[0027] The acquisition module is used to retrieve at least one block of Ethereum transactions, wherein the block includes multiple transactions;

[0028] The adding module is used to add a record identifier for the target opcode in the Ethereum Virtual Machine. The target opcode is the opcode corresponding to the specific operation and state variable of the smart contract interface call.

[0029] The processing module is used to execute the multiple transactions in the at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode, and obtain the execution result of the at least one block. The execution result is the specific operation and state variables of the smart contract interface call when executing the multiple transactions.

[0030] In one possible design of the second aspect, the target opcode includes: an opcode related to a blockchain or transaction;

[0031] Accordingly, the processing module, based on the record identifier of the target opcode, uses the Ethereum Virtual Machine to execute the multiple transactions in the at least one block to obtain the execution result of the at least one block, specifically for:

[0032] Based on the opcodes related to the blockchain or transactions, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block, and the first data corresponding to the opcodes related to the blockchain or transactions is recorded during the execution process;

[0033] The first data is used as the state variable, and the execution result is the specific operation of the smart contract interface call and the first data when executing the multiple transactions.

[0034] In another possible design of the second aspect, the target opcode further includes: an opcode related to memory or storage, and a push opcode;

[0035] The process of executing the multiple transactions in the at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode to obtain the execution result of the at least one block includes:

[0036] Based on the memory- or storage-related opcodes and the push opcodes, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block, and during the execution process, the second data corresponding to the memory- or storage-related opcodes and the third data corresponding to the push opcodes are recorded;

[0037] The second data and the third data are used as the specific operation, and the execution result is the second data, the third data, and the state variable called by the smart contract interface when executing the multiple transactions.

[0038] In another possible design, in the second aspect, after the Ethereum Virtual Machine is used to execute the plurality of transactions in the at least one block based on the record identifier of the target opcode to obtain the execution result of the at least one block, the apparatus further includes: a storage module;

[0039] The storage module is used to store the execution results of the at least one block.

[0040] In this possible design, the storage module is specifically used for:

[0041] Based on the execution result of at least one block, generate a log;

[0042] The logs are stored in the database.

[0043] In another possible design, the acquisition module is specifically used for:

[0044] Obtain a list of blockchains from the nodes of the blockchain of the Ethereum transaction, the list of blockchains including the identifier of the at least one block;

[0045] The at least one block is retrieved from the blockchain based on the identifier of the at least one block.

[0046] A third aspect of this application also provides a server, including: a processor and a memory;

[0047] The memory stores computer-executed instructions;

[0048] The processor executes the computer execution instructions, causing the server to perform the data extraction method as described in the first aspect and various possible designs above.

[0049] A fourth aspect of this application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the data extraction method as described in the first aspect and various possible designs above.

[0050] A fifth aspect of this application also provides a computer program product, including a computer program that, when executed by a processor, is used to implement the data extraction method as described in the first aspect and various possible designs above.

[0051] The data extraction method, apparatus, server, and storage medium provided in this application embodiment involve fetching at least one block of Ethereum transactions. Each block includes multiple transactions. A record identifier for a target opcode is added to the Ethereum Virtual Machine (EVM). The target opcode corresponds to the specific operation and state variables of the smart contract interface call. Based on the record identifier of the target opcode, the EVM executes multiple transactions within the at least one block to obtain the execution result of the at least one block. The execution result contains the specific operation and state variables of the smart contract interface call during the execution of multiple transactions. This technical solution, starting from the configured EVM and recording data related to the target opcode (i.e., opcodes related to blockchain / transactions, memory / storage, and push opcodes), achieves the goal of extracting specific operations and state variables of the smart contract interface call from Ethereum transactions. It also achieves the goal of collecting basic transaction states, providing foundational data for smart contract analysis and vulnerability analysis. Attached Figure Description

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

[0053] Figure 1 A flowchart illustrating an embodiment of the data extraction method provided in this application;

[0054] Figure 2 A schematic diagram of the architecture of the Ethereum Virtual Machine provided in the embodiments of this application;

[0055] Figure 3 A flowchart illustrating Embodiment 2 of the data extraction method provided in this application;

[0056] Figure 4 A schematic diagram of the data extraction device provided in the embodiments of this application;

[0057] Figure 5 This is a schematic diagram of the server structure provided in an embodiment of this application.

[0058] The accompanying drawings have illustrated specific embodiments of this disclosure, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this disclosure to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0059] To enable those skilled in the art to better understand the technical solutions of this application, the application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. However, this application can be implemented in many other ways different from those described above. Therefore, based on the embodiments provided in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0060] It should be noted that the terms "first," "second," "third," etc., in the claims, specification, and drawings of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. Such data are interchangeable where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown or described herein. Furthermore, the terms "comprising," "having," and their variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses. Exemplary embodiments will be described in detail herein, examples of which are illustrated in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0061] First, the technical terms and technical background involved in the embodiments of this application will be introduced and explained.

[0062] A virtual machine (VM) is a software-simulated complete computer system with full hardware functionality, running in a completely isolated environment. Any task that can be performed on a physical computer can also be performed in a VM. When creating a VM, a portion of the physical machine's hard drive and memory capacity is used as the VM's hard drive and memory capacity. Each VM has its own independent Complementary Metal-Oxide-Semiconductor (CMOS) hard drive and operating system, and can be operated just like a physical machine.

[0063] Ethereum Virtual Machine (EVM): A computing engine that facilitates the deployment and operation of smart contracts. The EVM exists to allow smart contract code written in Solidity by engineers to run in the Ethereum environment.

[0064] Machine codes (Opcodes): The EVM uses a series of instructions called "opcodes" to perform different tasks. There are more than 140 opcodes in the EVM that can execute different processes, so Ethereum describes it as Turing completion.

[0065] Fuel (Gas): The resource used to execute code within the EVM environment, measured in "gwei" (Ether units). Just as a car needs gasoline to power itself, the EVM also needs gasoline to perform its operations.

[0066] Smart contracts are code snippets that execute upon fulfillment of a predefined set of parameters. They use conditional programming (e.g., if y, then x) to perform operations. Smart contracts are immutable, autonomous, and transparent. These characteristics combine to make smart contracts particularly attractive, although they are not without their flaws. "Immunity" means that once deployed to a blockchain, the code of a smart contract cannot be changed. Smart contracts are autonomous because they can execute on their own without external control. They are transparent because the rules governing their performance are written in publicly available code. Different smart contracts can be thought of as different data processing flows.

[0067] A transaction: A transaction is an instruction from an Ethereum account. An example transaction is sending Ether from a wallet to an address. Here, the EVM is instructed to transfer value from one person's wallet to another location on the blockchain. Not every transaction on Ethereum involves a value transfer; some may transfer arbitrary data. The outcome of a transaction also depends on the recipient.

[0068] Stack: The Ethereum Virtual Machine maintains a uint256 stack to store local variables, function call parameters, and return addresses.

[0069] Memory: is a uint8 array used to store transient data when executing smart contracts.

[0070] Storage: A persistent associative mapping where uint256s are used as keys and uint256s are used as values. All fields and mappings of smart contracts are stored in storage.

[0071] Ethereum is one of the largest public decentralized computing platforms built on blockchain technology. It also provides Turing-complete computing capabilities in the form of smart contracts. Like many other software programs, smart contracts can be developed using high-level programming languages ​​such as Solidity, then compiled into bytecode, and then executed in the Ethereum Virtual Machine for each peer node in a peer-to-peer (P2P) network.

[0072] Smart contracts are immutable once deployed. Any immutable distributed ledger requires this functionality. Consequently, when vulnerabilities exist in a smart contract, they cannot be patched, leading to situations that are difficult to resolve and impact the entire process. Smart contracts are well-suited for applications with high requirements for trust, security, and durability, such as digital assets, voting, insurance, financial applications, prediction markets, property rights management, the Internet of Things, peer-to-peer transactions, and more.

[0073] Smart contracts are generic programs that execute on the blockchain. During execution, they can utilize three memory areas to perform data operations: the stack, memory, and storage. The (data) stack is a virtual stack used to store data. Note that the EVM also has a call stack, which is different from the data stack. Memory is a byte-addressable area allocated at runtime. Storage is a key-value store that maps 256-bit words to 256-bit words. Both the stack and memory are volatile, meaning that stored data is cleared after each execution. However, storage is persistent and can be used to store data across transactions. Therefore, the gas price of storage operations is much higher than that of stack and memory operations. A smart contract is a collection of code and data (state). A smart contract can be understood as a contract (a special transaction) written in code that can be automatically executed (event-driven) on the blockchain. In summary, the Ethereum Virtual Machine (EVM) is a stack-based big-endian virtual machine with a word length of 256 bits, used to run smart contracts on the Ethercell blockchain. Smart contracts are like ordinary accounts, except that they run Ethereum Virtual Machine bytecode when they receive transactions, allowing them to perform computations and further transactions. Transactions can carry 0 bytes or more of data, which is used to specify the type of interaction with the smart contract and any other information. Smart contract execution begins at the start of the bytecode. Each opcode is encoded as one byte, and in addition to pushing the opcode, a direct value is taken. All opcodes are popped from the top of the stack, and the result is pushed.

[0074] Currently, when it is necessary to perform subsequent summarization and other related processing on Ethereum transaction information, it is often necessary to obtain Ethereum transaction information in advance.

[0075] In existing technologies, the common implementation method of Ethereum transaction tracking devices is as follows: pull all Ethereum blocks, then parse the transaction content in all blocks, and analyze the transaction content to obtain the input content and execution result of the transaction.

[0076] Specifically, the input content of a transaction may include: the transaction initiating address from_address, the transaction receiving address to_address, and the call to the smart contract interface; the execution result of a transaction may include: the account balance and the execution result of the transaction.

[0077] Subsequently, the input content and execution results of the above transactions are summarized and analyzed using relevant algorithms to achieve the purpose of collecting transaction information.

[0078] However, existing Ethereum transaction tracking devices cannot track the state of smart contracts during execution. For example, the specific operations and state variables of the smart contract's interface calls cannot be obtained, especially for deeply nested smart contracts, making it impossible to analyze internal process changes. This prevents the provision of data support for more accurate analysis of issues involved in subsequent transaction information processing.

[0079] To address the aforementioned technical problems, the inventors' technical concept is as follows: In existing technologies, Ethereum transaction tracking devices pull all Ethereum blocks and parse the transaction content within the blocks to analyze the transaction input and execution results. However, because the existing Ethereum Virtual Machine (EVM) cannot obtain the specific operations and state variables of smart contract interface calls when parsing transaction content, adding corresponding functionality to the EVM by modifying the Go EVM to record opcode parameters (specifically, blockchain / transaction-related operation parameters, memory / storage-related operation parameters, and PUSH operation parameters) would allow obtaining the specific operations and state variables of the corresponding smart contract interface calls during transaction parsing, thereby enabling subsequent transaction analysis processing.

[0080] The technical solution of this application will be described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0081] Figure 1 This is a flowchart illustrating an embodiment of the data extraction method provided in this application. Figure 1 As shown, the method for extracting this data may include the following steps:

[0082] Step 11: Fetch at least one block of Ethereum transactions.

[0083] In this step, the user manipulates the server to make it pull at least one block of Ethereum transactions.

[0084] Optionally, a block refers to a combination of transactions, that is, a block includes multiple transactions. The block may specifically include: the time when the block was mined (pulled), the length of the block in the blockchain, the minimum fee per gas required to include the transactions in the block, the difficulty required to mine, the unique identifier of the block, the unique identifier of the previous block, the transactions contained in the block, the entire state of the system: account balance, contract storage, contract code and account nonce, and a hash, which, when used in conjunction with the unique identifier, can prove that the block has passed proof-of-work (nonce).

[0085] In one possible implementation, a list of blockchains is obtained from a node in the Ethereum transaction blockchain, the list including the identifier of the at least one block, and then the at least one block is pulled from the blockchain based on the identifier of the at least one block.

[0086] The method of fetching can be based on the order of the identifiers of each block in the blockchain list, or it can be based on other rules, which can be set by technical personnel.

[0087] Step 12: Add a record identifier for the target opcode in the Ethereum Virtual Machine.

[0088] The target opcode is the opcode corresponding to the specific operation and state variable of the smart contract interface call when the Ethereum Virtual Machine executes a block.

[0089] In this step, to address the technical problems existing in the prior art, the Ethereum Virtual Machine (EVM) needs to be configured accordingly before it analyzes the transaction content of at least one block. For example, an opcode module can be added to the EVM, which records the record identifier of the target opcode. Then, when the EVM executes a block, it can record the data involved in the target opcode during execution based on the target opcode in the opcode module, and use this data as the execution result corresponding to the at least one block.

[0090] Optionally, in the specific operations and state variables of the contract interface call, the target opcode involving the state variable can be an operation related to the blockchain / transaction; the target opcode involving the specific operation can be an operation related to memory / storage, as well as a PUSH operation.

[0091] In one possible implementation, a pre-configured Ethereum Virtual Machine (EVM) is used, which involves modifying an existing EVM: to record transaction traces, the Go Ethereum EVM is modified to record the parameters of the following three target opcodes.

[0092] Specifically, the parameters for the three target opcodes are as follows:

[0093] The first type is operations related to blockchain / transactions. This type includes opcodes that require retrieving data from the blockchain or the current transaction.

[0094] For example, a timestamp retrieves the Unix timestamp of the current block, which is the current block's Unix timestamp in seconds; a caller retrieves the address of the caller, which is the message caller address.

[0095] For example, Table 1 is an example table of operations related to blockchain / transactions, as shown in Table 1:

[0096] Table 1:

[0097] opcode Expression Notes timestamp block.timestamp current block's unix timestamp in seconds CALLER msg.caller message caller address

[0098] Among them, Expression, Notes, and msg.caller; block and timestamp.

[0099] The second type involves memory / storage related operations. Here, the trace extractor only records the operation codes for reading data from memory / storage.

[0100] For example, MLOAD means reading a (u)int 256 from memory; SLOAD means reading a (u)int256 from storage. An MLOAD is visible in memory; a SLOAD is visible in storage.

[0101] For example, Table 2 is an example table of memory / storage related operations, as shown in Table 2:

[0102] Table 2:

[0103] opcode Expression Notes MLOAD value = memory [ offset : offset + 32 ] reads a ( u ) int 256 from memory SLOAD value = storage [key] reads a ( u ) int256 from storage

[0104] Furthermore, there is no need to log the parameters of MSTORE and SSTORE, because the parameters of MSTORE and SSTORE only require data from the stack, which can be obtained from other parts of the trace.

[0105] MSTORE writes a uint8 to memory; SSTORE writes a uint256 to storage.

[0106] The third type is the PUSH operation. This type includes all PUSH opcodes, i.e., PUSH i, i = 1, 2, 3, ..., 32. This PUSH operation is visible on the stack.

[0107] For example, Table 3 is an example table of PUSH operations, as shown in Table 3:

[0108] Table 3:

[0109] opcode Expression Notes PUSH 1 PUSH(uint 8) Push a 1-byte value onto the stack. PUSH 2 PUSH(uint 16) Push a 2-byte value onto the stack. PUSH 3 PUSH(uint 24) Push a 3-byte value onto the stack. PUSH 4 PUSH(uint 32) Push a 4-byte value onto the stack. PUSH 5 PUSH(uint 40) Push a 5-byte value onto the stack. PUSH 6 PUSH(uint 48) Push a 6-byte value onto the stack. PUSH 7 PUSH (uint 56) Push a 7-byte value onto the stack. PUSH 8 PUSH(uint 64) Push an 8-byte value onto the stack. PUSH 9 PUSH(uint 72) Push a 9-byte value onto the stack. PUSH 10 PUSH (uint 80) Push a 10-byte value onto the stack. PUSH 11 PUSH (uint 88) Push an 11-byte value onto the stack. PUSH 12 PUSH (uint 96) Push a 12-byte value onto the stack. PUSH 13 PUSH(uint 104) Push a 13-byte value onto the stack. PUSH 14 PUSH (uint 112) Push a 14-byte value onto the stack. PUSH 15 PUSH (uint 120) Push a 15-byte value onto the stack. PUSH 16 PUSH(uint 128) Push a 16-byte value onto the stack. PUSH 17 PUSH(uint 136) Push a 17-byte value onto the stack. PUSH 18 PUSH(uint 144) Push an 18-byte value onto the stack. PUSH 19 PUSH (uint 152) Push a 19-byte value onto the stack. PUSH 20 PUSH (uint 160) Push a 20-byte value onto the stack. PUSH 21 PUSH (uint 168) Push a 21-byte value onto the stack. PUSH 22 PUSH (uint 176) Push a 22-byte value onto the stack. PUSH 23 PUSH(uint 184) Push a 23-byte value onto the stack. PUSH 24 PUSH (uint 192) Push a 24-byte value onto the stack. PUSH 25 PUSH (uint 200) Push a 25-byte value onto the stack. PUSH 26 PUSH(uint 208) Push a 26-byte value onto the stack. PUSH 27 PUSH (uint 216) Push a 27-byte value onto the stack. PUSH 28 PUSH(uint 224) Push a 28-byte value onto the stack. PUSH 29 PUSH(uint 232) Push a 29-byte value onto the stack. PUSH 30 PUSH(uint 240) Push a 30-byte value onto the stack. PUSH 31 PUSH(uint 248) Push a 31-byte value onto the stack. PUSH 32 PUSH(uint 256) Push a 32-byte value onto the stack.

[0110] This involves pushing an i-byte value onto the stack.

[0111] In addition, for other target opcodes, only the program counter (PC) value and OPCODE are recorded, because there is no need to record parameters.

[0112] Step 13: Based on the record identifier of the target opcode, execute multiple transactions in at least one block using the Ethereum Virtual Machine to obtain the execution result of at least one block.

[0113] The execution result includes the specific operations and state variables of the smart contract interface calls when executing multiple transactions.

[0114] In this step, based on the record identifier of the target opcode, when the Ethereum Virtual Machine executes multiple transactions in at least one block, the data corresponding to the target opcode during the execution process is recorded as the execution result of multiple transactions in at least one block. This execution result is also the specific operation and state variables of the smart contract interface call.

[0115] Optionally, in the specific operations and state variables of the contract interface call, the target opcode involving the state variable can be an operation related to the blockchain / transaction; the target opcode involving the specific operation can be an operation related to memory / storage, as well as a PUSH operation.

[0116] In one possible implementation, based on opcodes associated with the blockchain or transactions, multiple transactions in at least one block are executed using the Ethereum Virtual Machine. During execution, first data corresponding to the opcodes associated with the blockchain or transactions is recorded and used as a state variable.

[0117] In another possible implementation, based on memory- or storage-related opcodes and push opcodes, multiple transactions in at least one block are executed using the Ethereum Virtual Machine. During execution, second data corresponding to the memory- or storage-related opcodes and third data corresponding to the push opcodes are recorded, and the second and third data are used as specific operations.

[0118] For example, Table 4 is an example table of execution results, as shown in Table 4:

[0119] Table 4:

[0120] Target opcode Data corresponding to the target opcode For example opcodes related to blockchain or transactions First Data The time of fetching blocks, the address of the caller, etc. Opcodes related to memory or storage Second data The type of smart contract invoked, etc. Push operation code Third Data Specific calling process, etc.

[0121] Specifically, taking a transaction as an example, such as user A transferring funds to user B, when the Ethereum Virtual Machine executes the transfer operation, it calls the contract interface (i.e., calls the algorithm related to the transfer). Based on the target opcode, it records the specific operations of the algorithm involved in the transfer operation, as well as the changes in related transfer information (i.e., state variables).

[0122] Furthermore, executing block transactions sequentially using the modified Ethereum Virtual Machine can output the following: 1. Regular transaction parameters, such as transaction from_address, transaction to_address, and contract interface calls; 2. Transaction execution results, such as account balance and transaction execution result; 3. Relevant opcode parameters executed in the smart contract, such as blockchain / transaction-related operations, memory / storage-related operations, and PUSH operations.

[0123] Furthermore, after obtaining the execution results, the data in the execution results can be summarized and categorized according to certain rules, so as to facilitate subsequent analysis using relevant statistical algorithms, thereby providing a data foundation for smart contract analysis and vulnerability analysis.

[0124] The data extraction method provided in this application involves fetching at least one block of Ethereum transactions, where each block includes multiple transactions. A record identifier for a target opcode is added to the Ethereum Virtual Machine (EVM). The target opcode corresponds to the specific operation and state variables of the smart contract interface call. Based on the record identifier of the target opcode, the EVM executes multiple transactions within the at least one block to obtain the execution result of the at least one block. The execution result contains the specific operation and state variables of the smart contract interface call during the execution of multiple transactions. This technical solution starts with data related to the target opcode recorded in the configured EVM, specifically opcodes related to blockchain / transactions, memory / storage, and push opcodes. This achieves the goal of extracting specific operations and state variables of the smart contract interface call from Ethereum transactions, and also collects basic transaction states, providing foundational data for smart contract analysis and vulnerability analysis.

[0125] Based on the above embodiments in this application, Figure 2 This is a schematic diagram of the architecture of the Ethereum Virtual Machine provided in an embodiment of this application. Figure 2 As shown, the architecture of this Ethereum Virtual Machine includes an opcode record module 21.

[0126] Optionally, the architecture of the Ethereum Virtual Machine may also include: Virtual ROM 22, Machine state 23, World state 24, and Transaction module 25.

[0127] Among them, Virtual Drive 22 contains Ethereum Virtual Machine code; Machine State 23 contains program counter (PC), gas available, stack, and memory; World State 24 contains account storage.

[0128] For example, machine state 23 represents the current value of the current ledger state in a block, and world state 24 represents the current value of the ledger states in all other blocks.

[0129] As one implementation: In the original Ethereum Virtual Machine architecture, an opcode recording module 21 is built to filter relevant target opcodes. Data is input in the transaction business module 25. In the Ethereum Virtual Machine, the opcode recording module 21 filters relevant target opcodes and records them in the execution log module 26.

[0130] For example, the target opcode can be a parameter of the following three types:

[0131] Firstly, operations related to blockchain / transactions;

[0132] Secondly, operations related to memory / storage;

[0133] Thirdly, push (English: PUSH) operation.

[0134] Specifically, it pulls a complete list of blockchains from the blockchain nodes and utilizes... Figure 2 The provided Ethereum Virtual Machine executes at least one block transaction from the blockchain list in sequence and outputs an execution log. The execution log includes regular transaction parameters, such as transaction inputs (transaction from_address, transaction to_address, and calls to smart contract interfaces) and transaction execution results (account balance, transaction execution result). Data related to the target opcodes executed in the smart contract are also input into the execution log.

[0135] Table 5 below shows examples of traces for tracing code snippets.

[0136] Table 5:

[0137] 0; PUSH 1; 0 * 60 2; PUSH 1; 0 * 40 4; MSTORE 5; CALLDATASIZE; 0 * 144 6; ISZERO 7; PUSH 2; 0 * 20 e 10; JUMP I

[0138] Among them, the duration (ISZERO) means: if the difference from 0 is less than the range defined by the Epsilon parameter, it is considered equal to 0 and returns true; otherwise, it returns false, that is, (u)int256 is zero; CALLDATASIZE means the message data length in bytes; JUMP I means: if the condition is true, then conditional jump (conditional jump if condition is true).

[0139] A trace is a sequence of triples: {<PC>; <OPCODE>; <ARGS>}. Table 5 shows a transaction trace code segment. The main difference between the trace and the disassembled bytecode is that the recorded trace also includes the actual values ​​used in the transaction.

[0140] Furthermore, in combination Figure 2 The illustrated embodiments provide a detailed description of the data extraction method involved in the embodiments of this application. Figure 3 This is a flowchart illustrating a second embodiment of the data extraction method provided in this application. Figure 3 As shown, the method for extracting this data may include the following steps:

[0141] Step 31: Configure the Ethereum Virtual Machine to record the record identifier of the target opcode.

[0142] In this step, when it is necessary to extract the specific operations and state variables of the contract interface call, the Ethereum Virtual Machine is configured so that the execution result can be obtained in at least one block using the configured Ethereum Virtual Machine.

[0143] Optionally, the specific operations and state variables of the contract interface call may include the following target opcode parameters: first, opcodes related to blockchain / transaction; second, opcodes related to memory / storage; and third, push opcodes.

[0144] In other words, the specific process of configuring the Ethereum Virtual Machine can be: adding... Figure 2 The opcode recording module 21 shown is used to record the record identifier of the target opcode. During subsequent execution, the Ethereum Virtual Machine can use the record identifier of the target opcode to record the data related to the target opcode when executing the block.

[0145] In one possible implementation, blockchain / transaction-related operations, this type includes target opcodes that require retrieving data from the blockchain or the current transaction: memory / storage-related operations. Here, the tracer extractor only records target opcodes for reading data from memory / storage: PUSH operations. This type includes all PUSH opcodes, i.e., PUSH i, where i takes values ​​of 1, 2, 3, ..., 32.

[0146] As examples, in blockchain / transaction-related operations, such as `timestamp` to retrieve the Unix timestamp of the current block and `CALLER` to retrieve the caller's address. In memory / storage-related operations, such as `MLOAD` to read `a(u) int 256` from memory and `SLOAD` to read `(u) int 256` from storage. In PUSH operations, PUSH 1, PUSH 2, PUSH 3, ..., PUSH 32 respectively record pushing a 1-byte value onto the stack, pushing a 2-byte value onto the stack, pushing a 3-byte value onto the stack, ..., pushing a 32-byte value onto the stack, and the values ​​pushed onto the stack and read from storage / memory constitute the data for the specific operation.

[0147] Step 32: Fetch at least one block of Ethereum transactions.

[0148] In this step, the user manipulates the server to control it to pull at least one block on the Ethereum blockchain.

[0149] A block can include multiple transactions, and fetching a block means fetching multiple transactions from a batch of transactions.

[0150] In one possible implementation, a complete list of blockchains is pulled from an Ethereum blockchain node, which may contain at least one block.

[0151] As an example, during subsequent execution, blocks can be retrieved sequentially according to the order of blocks in the blockchain list.

[0152] It should be understood that there is no absolute order between steps 31 and 32. That is, the action of pulling at least one block of Ethereum and the action of modifying the Ethereum Virtual Machine to record the parameters of the following three opcodes can be triggered simultaneously or in any order.

[0153] Step 33: Based on the record identifier of the target opcode, execute multiple transactions in at least one block using the Ethereum Virtual Machine to obtain the execution result of at least one block.

[0154] In this step, the modified Ethereum Virtual Machine has the function of recording the specific operations and state variables of smart contract interface calls when executing at least one block of Ethereum transactions. That is, it can obtain the parameters of the target opcode related to the specific operations and state variables of smart contract interface calls of at least one block.

[0155] Optional, combined Figure 2An opcode recording module 21 was added to the original architecture. Based on the record identifier of the target opcode in the opcode recording module, the data related to the target opcode was filtered and recorded in the log, namely, the operation related to blockchain / transaction, the operation related to memory / storage, and the PUSH operation, which is the specific operation and state variable of the smart contract interface call.

[0156] In one possible implementation, when processing any block, the modified Ethereum uses the internal opcode recording module 21 to filter the three types of opcodes mentioned above to record the specific information corresponding to the three types of opcodes, namely, opcodes involving state variables (operations related to blockchain / transactions); and opcodes for specific operations (operations related to memory / storage, and PUSH operations).

[0157] In addition, combined Figure 2 In the original architecture, executing at least one block of an Ethereum transaction using the Ethereum Virtual Machine can also obtain the basic transaction state in the execution result, namely, the regular transaction parameters, such as transaction from_address, transaction to_address, and the call to the contract interface; as well as the output transaction execution result, such as the account balance and the execution result of the transaction.

[0158] Furthermore, the execution result may include the execution code and state variables obtained by the modified Ethereum Virtual Machine during the transaction execution process. In addition, it may also include the underlying transaction state obtained by the Ethereum Virtual Machine before the modification.

[0159] As an example, under the original architecture, when the Ethereum Virtual Machine executes a block (for example, A transferring funds to B), it only records the balance of B's ​​account after the transfer. However, when the modified Ethereum Virtual Machine executes the block, it also records the transfer time of A to B, the addresses of both parties, the balances before and after the transaction, and whether the transaction was successful.

[0160] Step 34: Store the execution results of at least one block.

[0161] In addition, the above-mentioned conventional transaction parameters, transaction execution results, and related opcode parameters executed in the output smart contract can be saved in log form.

[0162] Furthermore, all blocks of Ethereum transactions are executed, and the execution results of all blocks are obtained.

[0163] In order to enable subsequent analysis of smart contracts and timely detection of potential vulnerabilities in Ethereum, the execution results of the above steps are stored.

[0164] Furthermore, the execution results can be stored in a database.

[0165] Optionally, the database can be a repository for organizing, storing, and managing data according to a data structure. With the development of information technology and the market, data management is no longer just about storing and managing data, but has transformed into various data management methods required by users. There are many types of databases, ranging from the simplest tables storing various types of data to large-scale database systems capable of storing massive amounts of data, all of which have been widely used in various fields.

[0166] In one possible implementation, the execution results can be stored in a relational database management system database, such as Oracle, MySQL, Microsoft SQL Server, SQLite, PostgreSQL, or IBM DB2.

[0167] In another possible implementation, the execution results can be stored in a non-relational database management system database, such as key-value databases: Redis, Memcached, Riak; column-family databases: Bigtable, HBase, Cassandra; document databases: MongoDB, CouchDB, MarkLogic; and graph databases: Neo4j, InfoGrid.

[0168] Among them, relational database management systems have the following advantages:

[0169] The two-dimensional table structure closely resembles normal development logic (relational data models are easier to understand than hierarchical or network data models); it supports common Structured Query Language (SQL) statements; its rich integrity greatly reduces data redundancy and inconsistency. Furthermore, it consists entirely of table structures with a consistent file format; it allows for very complex queries between multiple tables using SQL statements; relational databases provide transaction support, ensuring the correct execution of transactions within the system, while also providing transaction recovery, rollback, concurrency control, and deadlock resolution; data is stored on disk, ensuring security and reliability.

[0170] The following advantages are available for non-relational database management systems:

[0171] NoSQL databases can store data in key-value pairs, documents, images, and other formats. They are flexible and widely applicable, while relational databases only support basic data types. They are also faster and more efficient. NoSQL (referring to non-relational databases in general) can use hard disks or random access storage, while relational databases can only use hard disks. Maintaining and processing large amounts of data is very easy and cost-effective. Relational databases offer advantages such as simple expansion, high concurrency, high stability, and low cost, enabling distributed data processing.

[0172] Furthermore, after obtaining the execution results, the data in the execution results can be summarized and categorized to facilitate subsequent analysis using relevant statistical algorithms, providing a data foundation for smart contract analysis and vulnerability analysis.

[0173] The data extraction method provided in this application involves configuring the Ethereum Virtual Machine (EVM) to record parameters of target opcodes, fetching at least one block of Ethereum transactions, then executing multiple transactions within that block using the EVM based on the recorded identifier of the target opcodes, obtaining the execution result of at least one block, and finally saving the at least one execution result. This technical solution, starting with modifying the EVM to record parameters of the following three target opcodes, achieves the goal of extracting specific operations and state variables recording smart contract interface calls and collecting basic transaction states from Ethereum transactions, providing foundational data for smart contract analysis and vulnerability analysis.

[0174] Based on the above data extraction method embodiments, Figure 4 A schematic diagram of the data extraction device provided in the embodiments of this application is shown below. Figure 4 As shown, the data extraction device includes: an acquisition module 41, an addition module 42, and a processing module 43;

[0175] Module 41 is used to retrieve at least one block of Ethereum transactions, where each block contains multiple transactions.

[0176] Add module 42 to add a record identifier for the target opcode in the Ethereum Virtual Machine. The target opcode is the opcode corresponding to the specific operation and state variable of the smart contract interface call.

[0177] Processing module 43 is used to execute multiple transactions in at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode, and obtain the execution result of at least one block. The execution result is the specific operation and state variables of the smart contract interface call when executing multiple transactions.

[0178] In one possible design of this application embodiment, the target opcode includes: an opcode related to blockchain or transaction;

[0179] Correspondingly, processing module 43, based on the record identifier of the target opcode, uses the Ethereum Virtual Machine to execute multiple transactions in at least one block to obtain the execution result of at least one block, specifically for:

[0180] Based on opcodes related to the blockchain or transactions, multiple transactions in at least one block are executed using the Ethereum Virtual Machine, and the first data corresponding to the opcodes related to the blockchain or transactions is recorded during the execution process;

[0181] The first data is used as a state variable, and the execution result is the specific operation of the smart contract interface call and the first data when executing multiple transactions.

[0182] In another possible design of this application embodiment, the target opcode further includes: an opcode related to memory or storage, and a push opcode;

[0183] Correspondingly, processing module 43, based on the record identifier of the target opcode, uses the Ethereum Virtual Machine to execute multiple transactions in at least one block to obtain the execution result of at least one block, specifically for:

[0184] Based on memory or storage-related opcodes and push opcodes, multiple transactions in at least one block are executed using the Ethereum Virtual Machine. During the execution process, second data corresponding to the memory or storage-related opcodes and third data corresponding to the push opcodes are recorded.

[0185] The second and third data are used as specific operations, and the execution result is the second data, third data, and state variables called by the smart contract interface when executing multiple transactions.

[0186] In another possible design of this application embodiment, after executing multiple transactions in at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode to obtain the execution result of at least one block, the device further includes: a storage module;

[0187] Storage module 44 is used to store the execution results of at least one block.

[0188] In this possible design, storage module 44 is specifically used for:

[0189] Generate logs based on the execution results of at least one block;

[0190] Store the logs in the database.

[0191] In another possible design of this application embodiment, the acquisition module 41 is specifically used for:

[0192] Obtain a list of blockchains from the nodes of the Ethereum transaction blockchain, which includes the identifier of at least one block;

[0193] Pull at least one block from the blockchain based on the identifier of at least one block.

[0194] The data extraction device provided in this application embodiment can be used to execute the technical solution corresponding to the data extraction method in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0195] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software through processing element calls; they can be fully implemented in hardware; or some modules can be implemented through processing element calls in software, while others are implemented in hardware. Moreover, these modules can be fully or partially integrated together, or implemented independently. The processing element mentioned here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.

[0196] Furthermore, Figure 5 This is a schematic diagram of the server structure provided in an embodiment of this application. Figure 5 As shown, the server may include: a processor 51, a memory 52, and computer program instructions stored in the memory 52 and executable on the processor 51.

[0197] The processor 51 executes computer execution instructions stored in the memory 52, causing the processor 51 to perform the scheme in the above embodiments. The processor 51 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, or discrete hardware components.

[0198] The memory 52 is connected to the processor 51 via the system bus and completes communication between them. The memory 52 is used to store computer program instructions.

[0199] Optionally, the server structure also includes a transceiver 53, which is connected to the processor 51 via a system bus and performs communication with it.

[0200] In implementation, the transceiver 53 can correspond to Figure 4 The acquisition module 41 in the illustrated embodiment.

[0201] The system bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0202] The server provided in this application embodiment can be used to execute the technical solution corresponding to the data extraction method in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0203] This application also provides a chip for executing instructions, which is used to execute the data extraction method described in the above embodiments.

[0204] This application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on a server, the server performs the data extraction method described in the above embodiments.

[0205] This application also provides a computer program product, including a computer program, which, when executed by a processor, is used to perform the data extraction method described in the above embodiments.

[0206] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage media or combinations thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage media can be any available medium accessible to general-purpose or special-purpose servers.

[0207] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

[0208] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

Claims

1. A method for extracting data, characterized in that, The method includes: Fetch at least one block of Ethereum transactions, the block comprising multiple transactions; Add a record identifier for the target opcode in the Ethereum Virtual Machine. The target opcode is the opcode corresponding to the specific operation and state variable of the smart contract interface call. Based on the record identifier of the target opcode, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block to obtain the execution result of the at least one block. The execution result is the specific operation and state variables of the smart contract interface call when executing the multiple transactions. The target opcode includes: opcodes related to blockchain or transactions; The process of executing the multiple transactions in the at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode to obtain the execution result of the at least one block includes: Based on the opcodes related to the blockchain or transactions, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block, and the first data corresponding to the opcodes related to the blockchain or transactions is recorded during the execution process; The first data is used as the state variable, and the execution result is the specific operation of the smart contract interface call and the first data when executing the multiple transactions.

2. The method according to claim 1, characterized in that, The target opcode also includes: opcodes related to memory or storage, and push opcodes; The process of executing the multiple transactions in the at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode to obtain the execution result of the at least one block includes: Based on the memory- or storage-related opcodes and the push opcodes, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block, and during the execution process, the second data corresponding to the memory- or storage-related opcodes and the third data corresponding to the push opcodes are recorded; The second data and the third data are used as the specific operation, and the execution result is the second data, the third data, and the state variable called by the smart contract interface when executing the multiple transactions.

3. The method according to claim 1, characterized in that, After executing the plurality of transactions in the at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode, and obtaining the execution result of the at least one block, the method further includes: Store the execution results of the at least one block.

4. The method according to claim 3, characterized in that, The storage of the execution results of the at least one block includes: Based on the execution result of at least one block, generate a log; The logs are stored in the database.

5. The method according to claim 1, characterized in that, The at least one block for fetching Ethereum transactions includes: Obtain a list of blockchains from the nodes of the blockchain of the Ethereum transaction, the list of blockchains including the identifier of the at least one block; The at least one block is retrieved from the blockchain based on the identifier of the at least one block.

6. A data extraction device, characterized in that, The device includes: A fetching module is used to fetch at least one block of Ethereum transactions, the block comprising multiple transactions; An add module is used to add a record identifier for the target opcode in the Ethereum Virtual Machine. The target opcode is the opcode corresponding to the specific operation and state variable of the smart contract interface call. The processing module is used to execute the multiple transactions in the at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode, and obtain the execution result of the at least one block, wherein the execution result is the specific operation and state variables of the smart contract interface call when executing the multiple transactions; The target opcode includes: opcodes related to blockchain or transactions; The process of executing the multiple transactions in the at least one block using the Ethereum Virtual Machine based on the record identifier of the target opcode to obtain the execution result of the at least one block includes: Based on the opcodes related to the blockchain or transactions, the Ethereum Virtual Machine is used to execute the multiple transactions in the at least one block, and the first data corresponding to the opcodes related to the blockchain or transactions is recorded during the execution process; The first data is used as the state variable, and the execution result is the specific operation of the smart contract interface call and the first data when executing the multiple transactions.

7. A server, characterized in that, include: Processor, memory, and computer program instructions stored in said memory and executable on the processor; When the processor executes the computer program instructions, it implements the data extraction method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the data extraction method as described in any one of claims 1 to 5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it is used to implement the data extraction method as described in any one of claims 1 to 5.

Images