Construction method and system of ethanum transaction behavior graph based on operation code sequence

Abstract

This invention provides a method and system for constructing an Ethereum transaction behavior graph based on opcode sequences. The method includes: collecting Ethereum transaction information by initiating transaction data replay on a Geth Ethereum client already instrumented on a cloud server; extracting external transaction features based on external Ethereum transaction types; extracting internal transaction features based on the discrimination method corresponding to internal Ethereum transaction types; and converting the extracted external and internal transaction features of each Ethereum transaction into a complete transaction behavior graph. By analyzing the account addresses and opcode sequences involved in the transactions, an Ethereum transaction behavior graph is constructed. This heterogeneous graph contains more detailed underlying information about on-chain transactions, providing a new approach for smart contract vulnerability detection. This method for constructing an Ethereum transaction behavior graph based on opcode sequences provides a solid data foundation for smart contract vulnerability detection.

Description

Technical Field

[0001] This document relates to the field of blockchain security and vulnerability detection technology, and in particular to a method and system for constructing Ethereum transaction behavior graphs based on opcode sequences. Background Technology

[0002] As Ethereum applications diversify and smart contracts become increasingly complex, the impact of smart contract security vulnerabilities is becoming more pronounced. Simultaneously, DApps running at the application layer are gradually exposing more security risks, making the security and reliability of smart contracts a new focus of research both domestically and internationally. While analytical techniques such as instrumentation and control flow graphs have been applied to smart contract vulnerability detection, and traditional static analysis methods like symbolic execution and taint analysis utilize these techniques, there is a dearth of large-scale datasets for smart contract vulnerability detection used in deep learning. Commonly used source data for deep learning model training includes smart contract source code and static opcode sequences, but these datasets lack the dynamic characteristics of transactions and are relatively small in size, failing to provide high-quality feature vectors for deep learning models.

[0003] Heterogeneous graphs, applicable to most application scenarios, have become a hot topic for blockchain researchers in the past two years. They convert smart contract source code or static opcode sequences into heterogeneous graphs to extract graph features for model training. However, a method for constructing heterogeneous graphs of transaction behavior based on transaction opcode sequences is still lacking. Therefore, it is necessary to provide a general method for constructing heterogeneous graphs of transaction behavior based on transaction opcode sequences to provide more detailed and comprehensive transaction behavior analysis. Existing technical solutions can be broadly divided into two categories: those based on source code and those based on on-chain transactions.

[0004] Source code-based schemes are static detection methods that extract semantic information from control flow and data flow as graph features; on-chain transaction-based schemes convert on-chain transaction logs into heterogeneous graphs for feature extraction. Source code-based schemes, used for constructing heterogeneous graphs, lack dynamic features of on-chain transactions; on-chain transaction-based schemes, also used for constructing heterogeneous graphs, lack semantic information from some internal transactions. Therefore, it is necessary to propose a method for constructing Ethereum transaction behavior graphs based on opcode sequences, enabling heterogeneous graphs to contain more detailed underlying information about on-chain transactions. Summary of the Invention

[0005] This specification provides one or more embodiments of a method for constructing an Ethereum transaction behavior graph based on an opcode sequence, including:

[0006] S1. Collect Ethereum transaction information by enabling transaction data replay in the Geth Ethereum client that has been instrumented on the cloud server;

[0007] S2. Extract external transaction features based on Ethereum external transaction types;

[0008] S3. Extract internal transaction features based on the discrimination method corresponding to the internal transaction type of Ethereum;

[0009] S4. Convert the external and internal transaction features extracted from each Ethereum transaction into a complete transaction behavior graph.

[0010] This specification provides one or more embodiments of a system for constructing an Ethereum transaction behavior graph based on an opcode sequence, including:

[0011] The instrumentation module is used to collect Ethereum transaction information by enabling the replay of transaction data on the instrumented Ethereum client Geth on the cloud server.

[0012] The external transaction feature module is used to extract external transaction features based on the Ethereum external transaction type.

[0013] The internal transaction feature module is used to extract internal transaction features based on the discrimination method corresponding to the Ethereum internal transaction type.

[0014] The Transaction Behavior Graph module is used to transform the external and internal transaction features extracted from each Ethereum transaction into a complete transaction behavior graph.

[0015] This invention utilizes all transaction information obtained after replaying Ethereum transaction data. Based on the method for distinguishing between external and internal transactions, it constructs an Ethereum transaction behavior graph by analyzing the account addresses and opcode sequences involved in the transactions. This heterogeneous graph contains more detailed underlying information about on-chain transactions, providing a new approach for smart contract vulnerability detection. This method of constructing an Ethereum transaction behavior graph based on opcode sequences provides a solid data foundation for smart contract vulnerability detection because the massive amount of Ethereum transaction data necessitates a massive amount of transaction behavior graph data. Attached Figure Description

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

[0017] Figure 1 This is a flowchart illustrating a method for constructing an Ethereum transaction behavior graph based on an opcode sequence, according to an embodiment of the present invention.

[0018] Figure 2This is a schematic diagram of an Ethereum transaction behavior graph construction system based on opcode sequences, according to an embodiment of the present invention.

[0019] Figure 3 This is a schematic diagram of internal transaction types in an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0021] Explanation of technical terms

[0022] Blockchain: Essentially, a blockchain is a shared database with traceable data. Nodes connecting the database form a peer-to-peer network and follow a consensus mechanism. On-chain data is encrypted and signed using cryptographic algorithms. Structurally, a blockchain is a linked list of blocks that store the transaction data of the nodes. The use of Merkle tree structure ensures that the block data cannot be tampered with.

[0023] Smart Contracts: A smart contract is a piece of immutable and transparent program code written in a high-level language (Solidity, Rust) and deployed on a blockchain. After deployment, the contract acts as a contract account, accepting transactions initiated by other accounts. Upon invocation, it automatically executes the pre-written program, receives input information, and completes the transfer and storage of virtual assets, all without third-party interference. However, because smart contracts cannot be modified once deployed, inherent security vulnerabilities can be easily exploited by hackers for profit.

[0024] Ethereum is an open-source public blockchain platform with smart contract functionality, and it is currently the world's largest platform for deploying blockchain applications.

[0025] External transactions: External transactions refer to transactions initiated by external accounts (EOAs) on the blockchain, involving the invocation of contracts between EOAs.

[0026] The recipient of an external transaction can be an EOA or a CA (Contract Account): if it is a CA, then a smart contract call transaction occurs, and one CA represents one smart contract.

[0027] Internal transactions: Internal transactions are transactions initiated by the smart contract itself. Within a smart contract, special functions can be used to trigger internal transactions. These functions are typically used for state transitions or processing logic within the contract. Internal transactions include five types: contract invocation, contract creation, and contract self-destruction.

[0028] Opcode Sequence: There are two definitions of opcode sequences. Definition 1 refers to the opcode sequence generated during transaction execution obtained by the Ethereum client Geth (go-ethereum) through instrumentation (inserting program code) on the Ethereum Virtual Machine. These transactions all involve smart contracts, and the opcode sequence consists of multiple assembly opcodes and parameters. Each opcode sequence represents the complete execution process of a transaction, containing one or more internal transactions. The sequence length varies, with the longest reaching hundreds of thousands of characters. Definition 2 refers to the instruction sequence generated by compiling the static source code of a smart contract into bytecode mapped according to Ethereum's official instructions. These instructions are the same as the opcodes in the first definition, and one smart contract corresponds to one opcode sequence. In this scheme, we adopt Definition 1, namely the opcode sequence based on Ethereum data replay proposed by Wang et al. Examples of both definitions are given below.

[0029] Definition 1: A truncated segment of a transaction opcode sequence

[0030] 0;PUSH1;;;60;1|2;PUSH1;;;40;1|4;MSTORE;;40,60;;1|5;CALLDATASIZE;;;0;1|6;ISZERO;;0;1;1|7;PUSH2;;;1f;1|10;JUMPI;;1f,1 ;;1|31;JUMPDEST;;;;1|32;PUSH2;;;11b;1|35;CALLVALUE;;;de0b6b3a7640000;1|36;PUSH1;;;0;1|38;DUP1;;;;1|39;DUP1;;;;1|40;P USH8;;;de0b6b3a7640000;1|49;DUP5;;;;1|50;LT;;de0b6b3a7640000,de0b6b3a7640000;0;1|51;PUSH2;;;1d5;1|54;JUMPI;;1d5,0;; 1|55;PUSH1;;;1;1|57;DUP1;;;;1|58;SLOAD;;1;0;1|59;DUP2;;;;1|60;ADD;;1,0;1;1|61;SWAP1;;;;1|62;DUP2;;;;1|63;SWAP1;;;;1. This sequence includes various assembly opcodes such as PUSH1, MSTORE, CALLDATASIZE, and JUMP1, as well as various parameters such as address and stack count, representing a part of the execution process of the transaction.

[0031] Definition 2: A bytecode fragment extracted from the compiled code of a specific Ethereum smart contract.

[0032] 0x608060405234801561001057600080fd5b506004361061014d576000356 0e01c806379ba5097116100c3578063a9059cbb1161007c578063a9059cbb. This fragment is composed of multiple hexadecimal bytecodes, which, according to the instruction set in the Ethereum Yellow Paper, can be mapped to the following instruction sequence: PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH2 0x0010 JUMPI PUSH1 0x00 DUP1 REVERT JUMPDEST POP PUSH1 0x04 CALLDATASIZE LT PUSH2 0x014d JUMPIPUSH1 0x00 CALLDATALOAD PUSH1 0xe0 SHR DUP1 PUSH4 0x79ba5097 GT PUSH2 0x00c3 JUMPI DUP1 PUSH4 0xa9059cbb GT PUSH2 0x007c JUMPI DUP1 PUSH4 0xa9059cbb. This sequence includes various assembly opcodes and multiple operands, representing the static execution process of a smart contract.

[0033] Method Implementation Examples

[0034] This invention provides a method for constructing an Ethereum transaction behavior graph based on an opcode sequence. Figure 1 This is a flowchart illustrating a method for constructing an Ethereum transaction behavior graph based on an opcode sequence, according to an embodiment of the present invention. Figure 1 As shown, the method for constructing an Ethereum transaction behavior graph based on an opcode sequence according to an embodiment of the present invention specifically includes:

[0035] S1. Collect Ethereum transaction information by enabling transaction data replay in the Geth Ethereum client that has been instrumented on the cloud server;

[0036] The collected Ethereum transaction information includes: external transaction initiator (fromaddr), external transaction receiver (toaddr), input parameters (inputdata), block number (blocknum), block timestamp (blocktimestamp), transaction hash (blockhash), and deployment contract address (re_contractaddress). Specifically, if the transaction is a smart contract call transaction, the transaction information will include the opcode sequence (trace).

[0037] S2. Extract external transaction features based on Ethereum external transaction types; Ethereum external transaction types include external account transfer transactions and smart contract call transactions; if the Ethereum external transaction type is an external account transfer transaction, then obtain the external transaction initiator and external transaction receiver, and represent the external feature as: the external transaction initiator points to the external transaction receiver, where the pointing type is external account transfer; if the Ethereum external transaction type is a smart contract call transaction, then obtain the external transaction initiator and external transaction receiver, and represent the external feature as: the external transaction initiator points to the external transaction receiver, where the pointing type is external call.

[0038] Ethereum external transactions are divided into two types: EOA (Externally Owned Accounts) transfer transactions and smart contract call transactions. Smart contract call transactions are transactions generated by EOA calling smart contracts. Because these transactions call smart contracts, they trigger one or more internal transactions.

[0039] External transaction feature extraction stage:

[0040] The external call feature extraction process applies to all Ethereum transactions. We store all transaction information after replaying the Ethereum transaction data in a database, including the external transaction initiator (fromaddr), external transaction receiver (toaddr), input parameters (inputdata), block number (blocknum), block timestamp (blocktimestamp), transaction hash (blockhash), and deployment contract address (re_contractaddress). Specifically, if the transaction is a smart contract call transaction, the transaction information will include an opcode sequence (trace).

[0041] We obtain the external transaction initiator (fromaddr) and external transaction receiver (toaddr) for each transaction, which can be represented as fromaddr->toaddr. For smart contract call transactions, the arrow type indicates an external call.

[0042] S3. Extract internal transaction features based on the discrimination method corresponding to the Ethereum internal transaction type. After completing the external transaction feature extraction, if the analyzed transaction is an EOA transfer transaction without internal transactions, it can directly enter the transaction behavior graph construction stage. If it is a smart contract call transaction with internal transactions, it is necessary to extract internal transaction features from the opcode sequence (trace) to improve the transaction behavior graph. Internal transactions include five types: contract call, contract creation, and contract self-destruction. The discrimination method for each type is different, and there may be multiple specific cases for a single type. The specific process for internal transaction feature extraction is as follows.

[0043] The specific process of feature extraction for contract call types:

[0044] This type is defined as an Ethereum contract calling functions of other contracts, excluding the `transfer` and `transferFrom` functions. The distinguishing opcodes are the four CALL opcodes (CALL, CALLCODE, STATICCALL, DELEGATECALL).

[0045] According to the Ethereum official definition of stack input during CALL opcode execution, our instrumentation code specifies that after the CALL opcode in the opcode sequence (trace), the following parameters will be output: caller, addr, value, inOffset, inSize, retOffset, retSize, and args. caller is the internal transaction initiator, addr is the internal transaction receiver, inOffset is the byte offset of the called data in memory, inSize is the size of the called data, retOffset is the byte offset of the returned data in memory, retSize is the size of the returned data, and args is the internal transaction input data. For internal transactions of contract call type, the args parameter must be non-empty, containing the function signature ID and the passed function parameters. The function signature ID does not include the two special IDs a9059cbb and 23b872dd. a9059cbb is the Keccak-256 encrypted ID of the transfer function signature transfer(address, uint256), and 23b872dd is the Keccak-256 encrypted ID of the transferFrom function signature transferFrom(address, address, uint256). Specifically, if a function that does not exist in the contract is called internally, the contract's fallback function will be triggered.

[0046] Based on the above principles, our specific feature extraction process is as follows.

[0047] We perform feature opcode matching on the opcode sequence (trace). If the match is successful, it indicates that there is an internal transaction containing a contract call type. Then we analyze the information carried after the CALL opcode.

[0048] We obtain the internal transaction initiator (caller) and the internal transaction receiver (addr). This internal transaction characteristic can be represented as caller->addr, with the arrow type indicating a contract call.

[0049] We perform feature opcode matching on the opcode sequence (trace). If a match is successful, we continue to analyze the information carried after the CALL opcode.

[0050] We obtain the internal transaction initiator (caller) and the internal transaction receiver (addr), and the internal transaction characteristic can be represented as caller->addr.

[0051] Therefore, our specific feature extraction process is as follows:

[0052] We perform feature opcode matching on the opcode sequence (trace). If a match is successful, we continue to analyze the information carried by the CALL and LOG opcodes.

[0053] We obtain the internal transaction initiator (caller), the internal transaction receiver (addr), the `from` parameter, and the `to` parameter. This internal transaction characteristic is divided into calling the Token contract. The Token contract calling characteristic can be represented as `caller->addr`, with the arrow type indicating a contract call.

[0054] The specific process of feature extraction for contract creation:

[0055] This type is defined as the creation of a new Ethereum contract. The distinguishing characteristic opcodes are two types of CREATE opcodes (CREATE, CREATE2).

[0056] According to Ethereum's official definition of the stack input when executing the CREATE opcode, our instrumentation code specifies that after the CREATE opcode in the opcode sequence (trace), parameters such as value, offset, size, and address will be output. Value is the amount transferred to the new contract account, offset is the byte offset in memory, size is the size of the bytes to be copied, and address is the address where the contract is created.

[0057] Internal transactions involving contract creation can be executed in two ways: either two contracts are created recursively, or a single contract is created.

[0058] Scenario 1: First, the external transaction initiator (fromaddr) initiates a call to public address 0x0, passing in the bytecode of the contract to be created as parameters, and successfully creates new contract 1. Then, the constructor of new contract 1 triggers the creation of new contract 2.

[0059] Scenario 2: The external transaction initiator (fromaddr) calls a function in the external transaction receiver (toaddr), which internally creates a new contract.

[0060] Based on the above principles, our specific feature extraction process is as follows:

[0061] We perform feature opcode matching on the opcode sequence (trace). If the match is successful, we continue with the following steps.

[0062] We obtain the external transaction receiver (toaddr) parameter. If this parameter is a public address (0x0), it indicates case one; if it is a regular CA address, it indicates case two. For case one, we obtain the deployment contract address (re_contractaddress) parameter and the address parameter after the CREATE opcode; the former is new contract 1, and the latter is new contract 2. This case can be represented as toaddr(0x0) -> re_contractaddress -> address, with both arrows indicating contract creation. For case two, we obtain the address parameter after the CREATE opcode; this address is the new contract. This case can be represented as toaddr -> address, with the arrow indicating contract creation.

[0063] The specific process of extracting features for contract self-destruction:

[0064] This type is defined as an Ethereum contract executing a self-destruct function and transferring the account balance to an external transaction initiator. The characteristic opcode for this type is SELFDESTRUCT.

[0065] According to the Ethereum official definition of the stack input when executing the SELFDESTRUCT opcode, we stipulate in our instrumentation code that after the CREATE opcode in the opcode sequence (trace), parameters such as beneficiary and address will be output. beneficiary is the beneficiary, and address is the self-destructing CA address.

[0066] Based on the above principles, our specific feature extraction process is as follows.

[0067] We perform feature opcode matching on the opcode sequence (trace). If the match is successful, it indicates that there is an internal transaction of the contract self-destruct type. Then we analyze the information carried after the SELFDESTRUCT opcode.

[0068] We obtain the internal transaction initiator (caller), internal transaction receiver (addr), beneficiary parameter, and address parameter. This internal transaction characteristic is divided into two parts: contract invocation and contract self-destruction. The contract invocation characteristic can be represented as caller->addr, with the arrow type indicating contract invocation; the contract self-destruction characteristic can be represented as address->beneficiary, with the arrow type indicating contract self-destruction.

[0069] S4. Convert the external and internal transaction features extracted from each Ethereum transaction into a complete transaction behavior graph.

[0070] After feature extraction in stages S2 and S3, we transform the features of each transaction into a complete transaction behavior graph. Please refer to [link / reference needed] for each type of graph. Figure 3 .

[0071] By employing the embodiments of the present invention, the following beneficial effects are achieved:

[0072] 1. This method for constructing an Ethereum transaction behavior graph based on opcode sequences utilizes all transaction information obtained after replaying Ethereum transaction data. Based on the method for distinguishing between external and internal transactions, it constructs an Ethereum transaction behavior graph by analyzing the account addresses (EOA, CA) and opcode sequences involved in the transaction. This heterogeneous graph contains more detailed underlying information about on-chain transactions, providing a new approach for smart contract vulnerability detection.

[0073] 2. The method for constructing an Ethereum transaction behavior graph based on opcode sequences is based on the massive amount of data in Ethereum transactions, which determines the massive amount of data in the transaction behavior graph, thus providing a good data foundation for smart contract vulnerability detection.

[0074] System Implementation Examples

[0075] This invention provides a system for constructing Ethereum transaction behavior graphs based on opcode sequences. Figure 2 This is a schematic diagram of an Ethereum transaction behavior graph construction system based on opcode sequences according to an embodiment of the present invention. Figure 2 As shown, the Ethereum transaction behavior graph construction system based on opcode sequences in this embodiment of the invention specifically includes:

[0076] Instrumentation module 20 is used to collect Ethereum transaction information by enabling the transaction data replay process of the instrumented Ethereum client Geth on the cloud server.

[0077] External transaction feature module 22 is used to extract external transaction features based on Ethereum external transaction types;

[0078] Internal transaction feature module 24 is used to extract internal transaction features according to the discrimination method corresponding to the Ethereum internal transaction type;

[0079] The transaction behavior graph module 26 is used to convert the external and internal transaction features extracted from each Ethereum transaction into a complete transaction behavior graph.

[0080] The instrumentation module 20 collects Ethereum transaction information including: external transaction initiator, external transaction recipient, input parameters, block number, block timestamp, transaction hash, and deployment contract address; if the transaction is a smart contract call transaction, the transaction information further includes an opcode sequence.

[0081] The external transaction feature module 22 is specifically used to: obtain the Ethereum external transaction type, which includes external account transfer transactions and smart contract call transactions;

[0082] If the Ethereum external transaction type is an external account transfer transaction, then the external transaction initiator and external transaction recipient are obtained, and the external feature is represented as: the external transaction initiator points to the external transaction recipient, where the type of the point is an external account transfer;

[0083] If the Ethereum external transaction type is a smart contract call transaction, then the external transaction initiator and external transaction receiver are obtained, and the external characteristics are represented as: the external transaction initiator points to the external transaction receiver, where the type of the pointer is an external call.

[0084] The internal transaction feature module 24 is specifically used for:

[0085] The opcode sequence is matched for feature opcodes. If the match is successful, the Ethereum internal transaction type is determined by the information carried after the CALL, LOG, CREATE, and SELFDESTRUCT opcodes. The five types of Ethereum internal transactions include: contract call, contract creation, and contract self-destruction.

[0086] If the Ethereum internal transaction type is a contract call, the internal transaction initiator and internal transaction receiver are obtained through the CALL opcode, and the internal transaction characteristics are represented as: the internal transaction initiator points to the internal transaction receiver, where the type of the pointer is a contract call;

[0087] If the Ethereum internal transaction type is "Create Contract", then the public address of the external transaction receiver is used to determine whether the creation contract recursively creates two contracts or creates a single contract during execution. If two contracts are created recursively, the internal transaction receiver, the deployment contract address parameter, and the address of the creation contract are obtained through the CREATE opcode, and the creation contract characteristic is represented as: the receiver points to the deployment contract address parameter, which points to the creation contract address, and both pointers are of type "Create Contract". If a single contract is created, the internal transaction receiver and the address of the creation contract are obtained, and the creation contract characteristic is represented as: the internal transaction receiver points to the creation contract address, where the pointer type is "Create Contract".

[0088] If the Ethereum internal transaction type is contract self-destruction, then the internal transaction initiator, internal transaction receiver, beneficiary, and self-destructing CA address are obtained through the SELFDESTRUCT opcode. The contract self-destruction is represented as two parts: contract call and contract self-destruction. The characteristics of the contract call part are: the internal transaction initiator points to the internal transaction receiver, and the type is contract call; the characteristics of the contract self-destruction part are: the self-destructing CA address points to the beneficiary, and the type is contract self-destruction.

[0089] The transaction behavior graph module 26 is specifically used for:

[0090] The external and internal transaction features extracted from each transaction are combined and converted into a heterogeneous graph. The heterogeneous graph is then output and saved as a file.

[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for constructing an Ethereum transaction behavior graph based on opcode sequences, characterized in that, include: S1. Collect Ethereum transaction information by enabling transaction data replay in the Geth Ethereum client that has been instrumented on the cloud server; S2. Extract external transaction features based on Ethereum external transaction types; S3. Extract internal transaction features based on the discrimination method corresponding to the internal transaction type of Ethereum; S4. Convert the external and internal transaction features extracted from each Ethereum transaction into a complete transaction behavior graph; S3 specifically includes: The opcode sequence is matched for feature opcodes. If the match is successful, the Ethereum internal transaction type is determined by the information carried after the CALL, LOG, CREATE, and SELFDESTRUCT opcodes. The Ethereum internal transactions include: contract calls, contract creation, and contract self-destruction. If the Ethereum internal transaction type is a contract call, the internal transaction initiator and internal transaction receiver are obtained through the CALL opcode, and the internal transaction characteristics are represented as: the internal transaction initiator points to the internal transaction receiver, where the type of the pointer is a contract call; If the Ethereum internal transaction type is "Create Contract", then the public address of the external transaction receiver is used to determine whether the creation contract recursively creates two contracts or creates a single contract during execution. If two contracts are created recursively, the internal transaction receiver, the deployment contract address parameter, and the address of the creation contract are obtained through the CREATE opcode, and the creation contract characteristic is represented as: the receiver points to the deployment contract address parameter, which points to the creation contract address, and both pointers are of type "Create Contract". If a single contract is created, the internal transaction receiver and the address of the creation contract are obtained, and the creation contract characteristic is represented as: the internal transaction receiver points to the creation contract address, where the pointer type is "Create Contract". If the Ethereum internal transaction type is contract self-destruction, then the internal transaction initiator, internal transaction receiver, beneficiary, and self-destructing CA address are obtained through the SELFDESTRUCT opcode. The contract self-destruction is represented as two parts: contract call and contract self-destruction. The characteristics of the contract call part are: the internal transaction initiator points to the internal transaction receiver, and the type is contract call; the characteristics of the contract self-destruction part are: the self-destructing CA address points to the beneficiary, and the type is contract self-destruction.

2. The method according to claim 1, characterized in that, The collected Ethereum transaction information includes: external transaction initiator, external transaction recipient, input parameters, block number, block timestamp, transaction hash, and deployment contract address; if the transaction is a smart contract call transaction, the transaction information further includes the opcode sequence.

3. The method according to claim 1, characterized in that, The Ethereum external transaction types include external account transfer transactions and smart contract call transactions; If the Ethereum external transaction type is an external account transfer transaction, then the external transaction initiator and external transaction recipient are obtained, and the external feature is represented as: the external transaction initiator points to the external transaction recipient, where the type of the point is an external account transfer; If the Ethereum external transaction type is a smart contract call transaction, then the external transaction initiator and external transaction receiver are obtained, and the external characteristics are represented as: the external transaction initiator points to the external transaction receiver, where the type of the pointer is an external call.

4. The method according to claim 1, characterized in that, S4 specifically includes: The external and internal transaction features extracted from each transaction are combined and converted into a heterogeneous graph. The heterogeneous graph is then output and saved as a file.

5. A system for constructing an Ethereum transaction behavior graph based on opcode sequences, characterized in that, include: The instrumentation module is used to collect Ethereum transaction information by enabling the replay of transaction data on the instrumented Ethereum client Geth on the cloud server. The external transaction feature module is used to extract external transaction features based on the Ethereum external transaction type. The internal transaction feature module is used to extract internal transaction features based on the discrimination method corresponding to the Ethereum internal transaction type. The transaction behavior graph module is used to convert the external and internal transaction features extracted from each Ethereum transaction into a complete transaction behavior graph; The internal transaction feature module is specifically used for: The opcode sequence is matched for feature opcodes. If the match is successful, the Ethereum internal transaction type is determined by the information carried after the CALL, LOG, CREATE, and SELFDESTRUCT opcodes. The Ethereum internal transactions include: contract calls, contract creation, and contract self-destruction. If the Ethereum internal transaction type is a contract call, the internal transaction initiator and internal transaction receiver are obtained through the CALL opcode, and the internal transaction characteristics are represented as: the internal transaction initiator points to the internal transaction receiver, where the type of the pointer is a contract call; If the Ethereum internal transaction type is "Create Contract", then the public address of the external transaction receiver is used to determine whether the creation contract recursively creates two contracts or creates a single contract during execution. If two contracts are created recursively, the internal transaction receiver, the deployment contract address parameter, and the address of the creation contract are obtained through the CREATE opcode, and the creation contract characteristic is represented as: the receiver points to the deployment contract address parameter, which points to the creation contract address, and both pointers are of type "Create Contract". If a single contract is created, the internal transaction receiver and the address of the creation contract are obtained, and the creation contract characteristic is represented as: the internal transaction receiver points to the creation contract address, where the pointer type is "Create Contract". If the Ethereum internal transaction type is contract self-destruction, then the internal transaction initiator, internal transaction receiver, beneficiary, and self-destructing CA address are obtained through the SELFDESTRUCT opcode. The contract self-destruction is represented as two parts: contract call and contract self-destruction. The characteristics of the contract call part are: the internal transaction initiator points to the internal transaction receiver, and the type is contract call; the characteristics of the contract self-destruction part are: the self-destructing CA address points to the beneficiary, and the type is contract self-destruction.

6. The system according to claim 5, characterized in that, The instrumentation module collects Ethereum transaction information including: external transaction initiator, external transaction recipient, input parameters, block number, block timestamp, transaction hash, and deployment contract address; if the transaction is a smart contract call transaction, the transaction information further includes an opcode sequence.

7. The system according to claim 5, characterized in that, The external transaction feature module is specifically used to: obtain the Ethereum external transaction type, which includes external account transfer transactions and smart contract call transactions; If the Ethereum external transaction type is an external account transfer transaction, then the external transaction initiator and external transaction recipient are obtained, and the external feature is represented as: the external transaction initiator points to the external transaction recipient, where the type of the point is an external account transfer; If the Ethereum external transaction type is a smart contract call transaction, then the external transaction initiator and external transaction receiver are obtained, and the external characteristics are represented as: the external transaction initiator points to the external transaction receiver, where the type of the pointer is an external call.

8. The system according to claim 5, characterized in that, The transaction behavior graph module is specifically used for: The external and internal transaction features extracted from each transaction are combined and converted into a heterogeneous graph. The heterogeneous graph is then output and saved as a file.

Images