Intelligent contract vulnerability detection method based on multi-level data dependence heterogeneous graph

Abstract

The invention discloses an intelligent contract vulnerability detection method based on a multi-level data dependence heterogeneous graph, and belongs to the technical field of intelligent contract security. Intelligent contract byte codes are used as input, contract byte codes are converted into operation codes, and a control-data heterogeneous graph with basic blocks as nodes is constructed; designing an in-block data dependency sub-graph, and forming multi-level data dependency with the inter-block data stream; based on the generated control-data heterogeneous graph, a feature weighted relation graph convolutional network is provided, and control flow and data flow feature weights are dynamically adjusted and optimized by using node static attributes such as dominating tree depth and the like, so that multi-modal semantic efficient aggregation is realized. According to the method, for the contract without a public source code on the block chain, vulnerability detection only for the bytecode of the intelligent contract is realized, and high detection efficiency can be achieved under the condition that the detection accuracy is guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of smart contract security technology, and in particular to a smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph. Background Art

[0002] Blockchain smart contracts, with their automated, tamper-proof execution mechanisms, have revolutionized transaction efficiency, security, and transparency, becoming a key technology driving decentralized innovation in finance, supply chains, the Internet of Things, and other fields. As their application scenarios expand, their business logic and code complexity are increasing, exposing security vulnerabilities such as reentrancy attacks and access control failures. In 2024 alone, access control vulnerabilities caused over $953 million in losses. Therefore, improving vulnerability detection capabilities before contract deployment has become a critical task in ensuring the security of the blockchain ecosystem.

[0003] Current smart contract vulnerability detection primarily relies on contract source code and bytecode. Source code-based detection research, such as Securify and ZEUS, leverages both natural and program semantics to improve detection accuracy and interpretability. In the Ethereum environment, only bytecode is stored after contract deployment, and the developer has the discretion to make the source code public. Given the lack of source code availability for most contracts, bytecode-based vulnerability detection techniques are particularly critical in practice.

[0004] Existing bytecode analysis tools, such as Mythril and Oyente, generally use symbolic execution technology to achieve high branch coverage vulnerability scanning. However, these tools are susceptible to path explosion and rely solely on static methods, resulting in low detection rates. In recent years, analysis methods that construct control flow graphs (CFGs) and combine them with graph neural networks have gradually gained popularity. However, these methods typically focus on control flow modeling and do not explicitly express data dependencies. This makes it difficult to capture semantic details such as stack operations and storage accesses, hindering the model's ability to model complex vulnerability behaviors. Summary of the Invention

[0005] This paper addresses the challenges of existing technologies by proposing a smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph. This method simultaneously captures the fine-grained semantics of both control and data flows. Based on static node properties such as dominator tree depth, it dynamically optimizes the weights of control and data flow features, achieving efficient aggregation of multimodal semantics and improving the detection accuracy of complex contract vulnerabilities.

[0006] To achieve the above objectives, the present invention is implemented through the following technical solutions: A smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph is performed according to the following steps:

[0007] Step S1, constructing a control-data contract heterogeneous graph: Parse the contract bytecode to be tested into opcodes, and construct a heterogeneous control flow graph HCFG with basic blocks as nodes based on the opcode sequence. On the basis of constructing the block-level control flow graph, further model the data dependency relationship between basic blocks, construct multi-level data dependency, and finally obtain a control-data heterogeneous graph. ,The control-data heterogeneous graph consists of a vertex set V and an edge set E, τ:V→A is the node type mapping function, φ:E→R is the edge type mapping function, where A and R represent the node type set and edge type set respectively, A≥2.R>1;

[0008] Step S2, multi-attribute static feature fusion: Analyze the heterogeneous graph, calculate the static attributes of each block node in the graph, and construct a multi-dimensional basic block feature vector;

[0009] Step S3, graph embedding process: vectorize the multimodal information of the basic block nodes in the heterogeneous graph, and finally concatenate the three types of feature vectors to form an initial node embedding vector containing structural, semantic and execution features;

[0010] Step S4: Design a feature-weighted graph convolutional network: Use node static properties to adaptively adjust the feature weights of control flow and data flow, model the semantic contributions of multiple types of edges through the graph attention mechanism, and finally generate the overall representation of the contract through graph-level aggregation. The vulnerability detection probability is output through the fully connected layer and Sigmoid function.

[0011] Furthermore, the specific process of constructing the control-data contract heterogeneous graph in step S1 is as follows:

[0012] Step S1.1: Take the EVM smart contract bytecode as input, parse it to generate an instruction sequence containing opcodes and their byte offsets, and use it to construct a heterogeneous graph.

[0013] Step S1.2: Construct the opcode sequence into a control flow graph with basic blocks as nodes, and define different types of basic blocks according to their functions and roles in the control flow, thereby constructing a heterogeneous control flow graph;

[0014] Step S1.3: Based on the heterogeneous control flow graph, capture the data flow relationship established between basic blocks through data entities and model the data dependency relationship between blocks;

[0015] Step S1.4: Traverse the opcode sequence in each basic block, construct a data dependency subgraph within the basic block, and characterize the relationship between opcodes within the block in a fine-grained manner;

[0016] Step S1.5: Combine the heterogeneous control flow graph with data dependency information to construct inter-block data flow edges and intra-block data dependency subgraphs, and finally obtain a control-data heterogeneous graph.

[0017] Furthermore, parsing the bytecode into the opcode in step S1.1 includes:

[0018] Split the continuous hexadecimal string into bytes in groups of two characters, and then map each byte to the corresponding EVM opcode instruction through a table lookup. For instructions that require immediate parameters, read the corresponding bytes after the opcode as parameters and combine them into values, generating a linear instruction sequence with the original bytecode offset in sequence.

[0019] Furthermore, the step S1.2 of constructing a heterogeneous control flow graph with basic blocks as nodes includes:

[0020] Traverse the opcode sequence and identify the longest continuous opcode sequence between the jump target and the jump instruction as a basic block. Each basic block is uniquely identified by the byte offset of the first opcode.

[0021] Based on the functions and roles of basic blocks in the control flow, the ENTRY, EXIT, COMMON, DISPATCHER, and FALLBACK node types are defined. ENTRY and EXIT represent the entry and exit of the control flow graph, respectively. A COMMON block is a sequence of opcodes located between the jump target and the jump instruction and executed in sequence, constituting the basic execution unit of the CFG. A DISPATCHE block is a COMMON block whose last instruction is RETURN or STOP, used to implement function distribution logic. A FALLBACK block is a separately defined DISPATCHER block that does not rely on call data during execution and does not contain any hash matching logic for function selection. Execution is terminated by the REVERT instruction, and it is used to handle the default behavior of unmatched function calls.

[0022] Construct directed edges based on the control transfer relationship between basic blocks to form a control flow graph;

[0023] By assigning opcode sequence characteristics or static execution properties to different types of nodes and edges, a heterogeneous control flow graph can be constructed that can reflect the program execution logic and structural characteristics.

[0024] Furthermore, the step S1.3 of establishing data dependencies between modules includes:

[0025] Step S1.3.1, traverse the basic block nodes in the control flow graph using a depth-first search strategy, and perform dependency analysis on the opcode sequence within each basic block in order;

[0026] Step S1.3.2: Use a virtual stack to simulate the access pattern of each opcode instruction to the stack, memory, and stored data entities, and record the data dependencies caused by read and write behaviors between opcodes;

[0027] Step S1.3.3: Based on the data interaction behavior, construct an opcode-level data dependency list to clarify the data flow relationship between instructions;

[0028] Step S1.3.4: Dependence on the EVM global state, introducing a virtual global block node GLOBAL as a unified source of external data;

[0029] Step S1.3.5: Aggregate the opcode-level dependencies within the same basic block and map them into data flow edges between basic blocks.

[0030] Furthermore, step S1.4 of constructing the intra-block data dependency subgraph includes:

[0031] For each opcode instruction sequence opcodes in a basic block, a data dependency edge set is constructed to form a complete intra-block data dependency subgraph;

[0032] The data dependency edge set E is dynamically generated during the traversal of the opcode instruction sequence. If an element pushed onto the stack by opcode A is referenced or consumed by opcode B, a directed edge e from A to B is added, indicating that the result of opcode A affects opcode B.

[0033] When opcode B uses these elements, the consumed elements are removed from the current stack, memory, or storage structure, and the newly pushed elements record the position of the current opcode;

[0034] Finally, the dependency edges are summarized to obtain the complete intra-block data dependency edge set E.

[0035] Furthermore, the multi-attribute static feature fusion in step S2 includes:

[0036] Step S2.1 calculates the dominator tree depth of the node

[0037] The dominance relationship is defined as follows: Heterogeneous graph For any two nodes , from the entry node All paths to node $v$ must pass through node , then it is called a node Dominant Node , recorded as The dominance relationship among all nodes constitutes a tree with the entry node The directed tree with root is the dominating tree, and the depth of the dominating tree is The calculation formula is as follows:

[0038]

[0039] Among them, represents the node The parent node in the document tree;

[0040] Step S2.2 calculates the PageRank centrality of each node

[0041] Given a heterogeneous graph , any node PageRank value It is obtained through iterative calculation. Specifically, in the iterative initialization phase, the PageRank of all nodes is set to , is the total number of nodes. As the iteration proceeds, the PageRank of each node is continuously updated. of The calculation formula is as follows:

[0042]

[0043] in, is the damping factor, For nodes The set of predecessor nodes; Representation node The out-degree of

[0044] For a basic block node ,in Represents a single opcode in the instruction set executed sequentially within the basic block. In order to quantify the static execution cost of the basic block, the function is defined To represent the operation code Static Gas cost;

[0045] Based on the above definition, the basic block Total Gas consumption It can be calculated by summing the gas costs of all opcodes in a basic block, as follows:

[0046]

[0047] When the PageRank value change of all nodes in two adjacent iterations is lower than the preset convergence threshold , or when the specified maximum number of iterations is reached, the calculation process terminates and the final result is That is the node The PageRank centrality score of

[0048] Step S2.3 Calculate the Gas consumption of each block node

[0049] For a basic block node ,in Represents a single opcode in the instruction set executed sequentially within the basic block. In order to quantify the static execution cost of the basic block, the function is defined To represent the operation code Static Gas cost;

[0050] Based on the above definition, the basic block Total Gas consumption It can be calculated by summing the gas costs of all opcodes in a basic block, as follows:

[0051]

[0052] Step S2.4 combines the three numerical values ​​of dominance tree depth, PageRank value, and Gas consumption with the block type to form a multi-dimensional static feature.

[0053] Furthermore, the graph embedding process in step S3 includes:

[0054] Step S3.1: The opcode sequence is mapped into a fixed-length vector using the pre-trained Word2Vec model and average pooled to generate the overall representation.

[0055] Step S3.2: For the intra-block data dependency subgraph, the edge vector of each edge is generated by the Hadamard product of the node vectors at both ends, and then the subgraph representation is obtained by average pooling;

[0056] Step S3.3: Static attributes include block node type, dominator tree depth, gas consumption, and PageRank centrality. Block node type is represented by one-hot encoding. The latter three numerical attributes are normalized and concatenated with the block type vector to form a static feature vector representation.

[0057] Step S3.4: Finally, the three types of feature vectors, namely, the opcode sequence, the data dependency subgraph, and the static attribute, are concatenated to form the initial embedding vector of the node, which serves as the input basis of the graph convolutional network.

[0058] Furthermore, the step S4 of designing a feature weight relationship graph convolutional network includes:

[0059] Step S4.1, dynamically adjust the control flow and data flow feature weights using node static attributes;

[0060] The initial representation of each basic block node is as follows:

[0061]

[0062] in, is the opcode sequence embedded in the control flow, is the edge vector aggregation representation of the data dependency subgraph, Represents a static attribute vector, using static attribute features Dynamically generate attention weights:

[0063]

[0064] in, As a learnable parameter, the generated attention weight is used to weightedly fuse the control and data path features to form the updated node features:

[0065]

[0066] Step S4.2: Adaptively model the semantic contributions of multiple types of edges through the graph attention mechanism;

[0067] The FW-RGCN feature weight relation graph convolutional network introduces a relational perception mechanism in the graph convolution process, For any side type , the model learns an independent linear mapping for it:

[0068]

[0069] A multi-head attention mechanism is used to aggregate information between nodes. The attention weight is calculated as follows:

[0070]

[0071] in, Indicates the edge type The set of adjacent nodes under is the attention vector, Represents the splicing operation, which uses weighted summation to aggregate neighbor information and splice the output of all heads, and updates the node representation through nonlinear activation:

[0072]

[0073]

[0074] in, and The above convolution modules can be stacked in multiple layers in the network to achieve deep modeling and fusion of multi-path structural information.

[0075] Step S4.3: Input the feature learning results into the fully connected layer and the Sigmoid layer to obtain the probability of various vulnerabilities existing in the smart contract to be tested. Vulnerabilities with probabilities greater than the set value are regarded as the most likely vulnerabilities in the smart contract to be tested.

[0076] After multi-layer graph convolution, the node representation The graph representation is obtained through graph-level aggregation operation, generating a graph-level representation:

[0077]

[0078] in, Represents the total number of basic block nodes in the graph. Finally, it passes through a fully connected mapping layer and uses the Sigmoid activation function to output the predicted vulnerability probability:

[0079]

[0080] in, In order to predict the vulnerability probability, binary cross entropy is used as the optimization target in the model training phase to measure the deviation between the predicted results and the true labels.

[0081] Compared with the prior art, the present invention has the following beneficial effects.

[0082] 1. By constructing a data dependency subgraph within a block, the data dependency relationship between opcodes within a basic block is modeled at the opcode granularity to improve the integrity of data dependency information.

[0083] 2. This invention measures the importance of nodes in the program graph by introducing static execution attributes such as dominator tree depth, PageRank centrality, and gas consumption, and provides a multi-dimensional basis for node importance.

[0084] 3. The present invention proposes a feature-weighted relational graph convolutional network, which dynamically adjusts the weights of control flow and data flow features based on the static execution properties of nodes, adaptively balances the importance of control flow and data flow features, and realizes efficient aggregation of multimodal semantics.

[0085] 4. By designing a heterogeneous graph modeling framework that integrates control flow and multi-level data flow, the model's ability to express complex semantic patterns is significantly enhanced, and the F1 score in multiple vulnerability detection tasks is improved by 2.5%–11.9%. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] Figure 1 This is a schematic diagram of the overall structure of a method for detecting smart contract vulnerabilities by integrating a heterogeneous graph with multi-level data dependencies in an embodiment of the present invention.

[0087] Figure 2 This is a schematic diagram of source code compilation in an embodiment of the present invention.

[0088] Figure 3 1 is a schematic diagram of bytecode parsing in an embodiment of the present invention.

[0089] Figure 4 It is a fusion control-data contract heterogeneous graph designed in an embodiment of the present invention.

[0090] Figure 5 This is a schematic diagram of the inter-block data flow constructed in an embodiment of the present invention.

[0091] Figure 6 It is the intra-block data dependency subgraph constructed in the embodiment of the present invention.

[0092] Figure 7 Schematic diagram of the feature weight relationship graph convolutional network designed in an embodiment of the present invention.

[0093] Figure 8 This is a diagram of data flow between blocks.

[0094] Figure 9 It is the specific process of the data dependency subgraph within the block. DETAILED DESCRIPTION

[0095] The following will describe the embodiments of the present invention in detail with reference to the accompanying drawings and examples, so as to fully understand and implement the process of how the present invention applies technical means to solve technical problems and achieve technical effects.

[0096] like Figure 1 As shown in FIG, the present invention is based on a smart contract vulnerability detection method of a multi-level data dependency heterogeneous graph, which specifically includes the following four steps:

[0097] Step S1: Constructing a heterogeneous graph: Based on the EVM bytecode, first construct a control flow graph with basic blocks as nodes and define five main basic block node types; then traverse the basic blocks through depth-first search, analyze and introduce inter-block data flow edges; finally, for the inside of the basic block, construct an intra-block data dependency subgraph with opcode as the granularity to capture fine-grained data dependencies and form a multi-level (inter-block and intra-block) semantic modeling structure; introduce data flow information into the control heterogeneous graph, and finally obtain a control-data heterogeneous graph ,The control-data heterogeneous graph consists of a vertex set V and an edge set E. τ:V→A is the node type mapping function, φ:E→R is the edge type mapping function, where A and R represent the node type set and edge type set respectively, A≥2.R>1.

[0098] Step S1.1: Parse the EVM smart contract bytecode and identify and extract the runtime bytecode part in the bytecode according to the identifiers defined in the Ethereum official document, such as Figure 2As shown. The bytecode is represented as a string of hexadecimal digits, where every two hexadecimal characters form a byte and are mapped to the corresponding opcode instruction (e.g. the string 6080 is parsed as PUSH1 0x80). The bytecode string is decoded by the decompiler to generate an instruction sequence containing the opcode and its byte offset, as shown in Figure 3 As shown, it serves as the basis for subsequent control flow graph construction.

[0099] Step S1.2: To avoid the increased computational complexity associated with directly using opcodes as graph nodes, the present invention employs a CFG construction method using basic blocks as nodes. A basic block is defined as a maximally contiguous sequence of opcodes between a jump target and a jump instruction. Therefore, whenever a program encounters an opcode that affects control flow, it is considered a basic block boundary. Opcodes such as JUMP, JUMPI, STOP, REVERT, RETURN, INVALID, and SELFDESTRUCT mark the end of a basic block; the JUMPDEST opcode marks the beginning of a new basic block. Figure 4 The block-level control flow graph generated based on the runtime bytecode is shown. Each basic block uses the bytecode offset of its first opcode as a unique identifier. The present invention defines five main basic block node types: ENTRY, EXIT, COMMON, DISPATCHER and FALLBACK. Specifically, ENTRY and EXIT represent the entry and exit of the control flow graph, respectively, and are used to unify the start and end paths of the program; the COMMON block refers to a sequence of opcodes located between the jump target and the jump instruction and executed in sequence, which constitutes the basic execution unit of CFG; the DISPATCHE block refers to a COMMON block whose last instruction is RETURN or STOP, which is usually used to implement function distribution logic; the FALLBACK block is a special type of DISPATCHER block, which is characterized by not relying on call data during execution and does not contain any hash matching logic for function selection. It often terminates execution through the REVERT instruction and is used to handle the default behavior of unmatched function calls.

[0100] Step S1.3: Building upon the block-level control flow graph, further model the data dependencies between basic blocks. The core of this process is capturing the data flow relationships established between opcodes through data entities (stack, memory, and storage). Since the execution of all opcodes in the Ethereum Virtual Machine (EVM) essentially boils down to accessing and manipulating these three core data entities, a virtual stack structure is used to model and track them.

[0101] Specifically, a depth-first search (DFS) traversal strategy is first applied to the basic block nodes in the control flow graph, and a dependency analysis is performed on the opcode sequence within each basic block. The opcode instructions within each basic block are executed sequentially, and their access patterns to data entities are simulated on the virtual stack. The data dependencies caused by the read and write behaviors between opcodes are recorded. Although dependencies actually exist at the opcode level, because the graph structure is constructed with basic blocks as nodes, data dependency edges cannot be precisely located to a specific opcode and can only be mapped to the basic block to which it belongs. To this end, the present invention aggregates the data interaction relationships at the opcode level into block-level dependency edges, thereby forming a cross-block data flow graph between basic blocks.

[0102] Step S1.4: Inter-block data flow is constructed as follows Figure 8 As shown. The read and write semantics of each opcode are modeled as a triple structure, which describes its interaction mode in the three dimensions of stack, memory and storage. The semantic triple of each dimension is expressed in the following format: (1) the index list of the existing elements of the referenced data entity; (2) the index list of the consumed elements; (3) the number of newly pushed elements. For example, the semantics of the opcode ADD on the stack are , meaning it pops two elements from the stack to participate in the calculation and pushes the result back onto the stack.

[0103] In addition, to handle the dependency of some opcodes (such as TIMESTAMP and DIFFICULTY) on the EVM global state, a virtual global block node GLOBAL is introduced as a unified source of external data. All basic blocks involving global attribute references are connected to this GLOBAL node through data flow edges, thus ensuring that the graph structure has complete semantic coverage of external dependencies, such as Figure 6 shown.

[0104] Step S1.5: Fine-grained data dependency embedding. Establishing coarse-grained abstraction of data flow dependencies only at the node granularity of basic blocks will result in severe dilution or even loss of data dependency information within the block. To this end, a solution is proposed to construct a data dependency subgraph within the basic block to fine-grainedly depict the relationship between opcodes within the block and retain data dependency information to the maximum extent. Figure 9 As shown in Figure 2, the specific process of building a data dependency subgraph within a block is given.

[0105] For each opcode instruction sequence opcodes within a basic block, a data dependency edge set is constructed to form a complete intra-block data dependency subgraph. The data dependency edge set E is dynamically generated during the traversal of the opcode instruction sequence. The generation rule is as follows: If an element pushed onto the stack by opcode A is referenced or consumed by opcode B, a directed edge e is added from A to B, indicating that the result of opcode A affects opcode B. When opcode B uses these elements, the consumed elements are removed from the current stack, memory, or storage structure, and the newly pushed elements record the position of the current opcode (i.e., offset). Finally, the dependency edges are summarized to obtain the complete intra-block data dependency edge set E.

[0106] This process ensures that the dependencies between all opcodes can be preserved as much as possible within the basic block, and finally obtains the control-data heterogeneous graph G.

[0107] Step S2: Multi-attribute static feature fusion: Three static attributes, dominator tree depth, PageRank centrality, and gas consumption, are introduced to quantify the structural importance and execution characteristics of nodes in the contract. Dominator tree depth reflects the hierarchical nesting of nodes in the control flow, revealing key decision points; PageRank centrality measures the core role of nodes in information flow and identifies data flow hubs; gas consumption is based on the static cost of opcodes defined in the EVM Yellow Paper, and is accumulated to obtain the basic block resource usage cost. These three attributes enhance the semantic expression of nodes from the dimensions of logical hierarchy, information hub, and execution cost, respectively, providing a multi-dimensional basis for subsequent feature weighting.

[0108] Step S2.1: Calculate the dominance tree depth of the node. Construct a dominance tree based on the heterogeneous graph. If all paths from the entry node to the node must pass through the node, it is called dominance. The dominance tree depth of a node is defined as the depth of its parent node + 1. The depth of the entry node is 0, reflecting the logical nesting level of the node in the control flow. First, the dominance relationship is defined as follows: Heterogeneous graph For any two nodes , if from the entry node To Node All paths must pass through the node , then it is called a node Dominant Node , recorded as The dominance relationship between all nodes constitutes a tree with the entry node The directed tree with root is called dominator tree. The depth of dominator tree is The calculation formula is as follows:

[0109]

[0110] Among them, represents the node The parent node in the document tree.

[0111] Step S2.2: Calculate the PageRank centrality of each node and initialize the PageRank value of all nodes to ,in is the total number of nodes, and the PageRank value is updated through the iterative formula until convergence or the maximum number of iterations is reached; the calculation steps for PageRank are as follows: Given a heterogeneous graph , any node PageRank value Specifically, in the iterative initialization phase, the PageRank of all nodes is set to , is the total number of nodes. As the iteration proceeds, the PageRank of each node is continuously updated. of The calculation formula is as follows.

[0112]

[0113] in, is the damping factor, which is used to simulate the probability that a random visitor continues to visit or jump to any node along the edge of the graph; For nodes The set of predecessor nodes; Representation node The out-degree.

[0114] When the PageRank value change of all nodes in two adjacent iterations is lower than the preset convergence threshold , or when the specified maximum number of iterations is reached, the calculation process terminates. That is the node The PageRank centrality score of .

[0115] Step S2.3: Calculate the gas consumption of each block node. Based on the static cost of each opcode defined in the EVM Yellow Paper, sum the costs of all opcodes in the basic block to quantify the resource usage cost of the node. Gas consumption is used as the EVM-specific node execution cost. The calculation steps are as follows. For a basic block node ,in Represents a single opcode in the instruction set executed sequentially within the basic block. In order to quantify the static execution cost of the basic block, define the function To represent the operation code The static gas cost of . This cost is determined by the EVM Yellow Paper.

[0116] Based on the above definition, the basic block Total Gas consumption It can be calculated by summing the gas costs of all opcodes in a basic block, as follows:

[0117]

[0118] Step S2.4 combines the three values ​​of dominance tree depth, PageRank value, and gas consumption with the block type to form a multi-dimensional static feature. The introduction of these three static attributes quantifies the structural importance, logical complexity, and execution cost of nodes in the heterogeneous contract graph, providing weight guidance for subsequent feature learning.

[0119] Step S3: Graph Embedding: This vectorizes the multimodal information of basic block nodes in the heterogeneous graph. The opcode sequence is mapped to a vector using Word2Vec and average pooled to generate a global representation. The edge vectors of the data dependency subgraph within the block are generated by the Hadamard product of the node vectors at both ends, and then average pooled to obtain the subgraph representation. Static attributes, including block type (one-hot encoding), dominator tree depth, gas consumption, and PageRank centrality (normalized), are concatenated into a static semantic vector. Finally, the opcode sequence, data dependency subgraph, and static attributes are concatenated to form an initial node embedding vector that encompasses structural, semantic, and execution features, providing a unified input foundation for the graph convolutional network.

[0120] After the heterogeneous contract graph is constructed, in order to achieve deep modeling of node-level vulnerability semantics, each basic block node in the graph needs to be vectorized. Specifically, each basic block node The multimodal semantic information of is composed of three types of features: opcode sequence, data dependency subgraph and static attributes.

[0121] Step S3.1: First, for the basic block Internal opcode sequence , each opcode Mapped to a fixed-length vector through the pre-trained Word2Vec model In order to extract the vector representation of the entire opcode sequence, an average pooling strategy is used for aggregation, and the formula is as follows:

[0122]

[0123] Step S3.2: Secondly, for the data dependency subgraph within the basic block , where each edge Represents data dependencies between opcodes. Defines the embedding vector of an edge as the Hadamard product (element-wise multiplication) of the node vectors at its ends, effectively preserving the semantic interaction information between nodes with low computational overhead.

[0124]

[0125] Further average pooling is performed on all edge vectors to obtain the vector representation of the block node data dependency subgraph:

[0126]

[0127] Step S3.3: Finally, the static attribute vector Consists of four parts: block type, dominator tree depth Gas consumption and PageRank centrality Among them, the block type is represented by one-hot encoding as ( The numerical attributes of the latter three are normalized and concatenated with the block type vector to form a static semantic representation:

[0128]

[0129] Step S3.4, Node The overall input vector of is composed of the above three types of features:

[0130]

[0131] In step S3.4, the three feature vectors—opcode sequence, data dependency subgraph, and static attribute—are concatenated to form the initial node embedding vector, which serves as the input for the graph convolutional network. This constructed node vector serves as the initial embedding for the FW-RGCN network, carrying multimodal semantic information and providing a unified representation for subsequent relationship modeling and vulnerability detection.

[0132] Step S4: Feature-Weighted Relational Graph Convolutional Network: This design utilizes a dynamic weighting mechanism and a relationship-aware module to achieve multimodal semantic aggregation. First, attention weights are generated using static node attributes to adaptively adjust the fusion ratio of control flow (opcode sequence) and data flow (data dependency subgraph) features, highlighting key features in different vulnerability scenarios. Second, a relationship-aware graph convolutional module learns independent linear mappings for each edge type in the heterogeneous graph. This, combined with a multi-head attention mechanism, aggregates neighboring node information to model the structural differences among multiple edge types. Finally, graph-level aggregation generates a holistic representation of the contract, which is then output via a fully connected layer and a sigmoid function. This network improves the modeling accuracy of complex semantic patterns through static attribute-driven weight tuning and relationship-type-aware feature learning.

[0133] Step S4.1: Feature Weight Relational Graph Convolutional Network. To solve the problem of difficulty in uniformly modeling the contribution of control flow and data flow features in smart contracts, FW-RGCN uses static node attributes to dynamically adjust the weights of control flow and data flow features, adaptively models the semantic contribution of multiple types of edges through the relationship graph attention mechanism, and combines graph convolution to achieve joint learning of structural dependencies and feature semantics. Figure 7 As shown in the figure, control flow and data flow information are first fused through a dynamic weighting mechanism driven by static attributes to generate semantically enhanced node representations. Then, the structural information of multiple types of edges is combined and input into the relationship-aware graph convolution module to model the structural semantics of heterogeneous graphs. Finally, the output of the graph convolution passes through a fully connected layer and Sigmoid activation to generate vulnerability probabilities for smart contract vulnerability identification.

[0134] Step S4.2: Dynamic feature weighting mechanism driven by static properties. In contract bytecode, the contribution of control flow paths and data dependency paths to different vulnerability types may vary significantly. To adapt to the different importance of control flow and data flow for vulnerability determination in different scenarios, FW-RGCN introduces a dynamic feature weighting mechanism driven by static properties. The initial representation of each basic block node is as follows:

[0135]

[0136] in, is the opcode sequence embedded in the control flow, is the edge vector aggregation representation of the data dependency subgraph, Represents a static attribute vector. Using static attribute features Dynamically generate attention weights:

[0137]

[0138] in, is a learnable parameter. The generated attention weight is used to weightedly fuse the control and data path features to form the updated node features:

[0139]

[0140] Step S4.3: Relationship-aware graph convolution. In order to model the structural differences introduced by multiple relationship edges in the heterogeneous contract graph, FW-RGCN introduces a relationship-aware mechanism in the graph convolution process. For any side type , the model learns an independent linear mapping for it:

[0141]

[0142] A multi-head attention mechanism is used to aggregate information between nodes. The attention weight is calculated as follows:

[0143]

[0144] in, Indicates the edge type The set of adjacent nodes under is the attention vector, Represents the concatenation operation. It aggregates neighbor information using weighted summation and concatenates the outputs of all heads. It then updates the node representation through nonlinear activation:

[0145]

[0146]

[0147] in, and is the projection layer parameter. The above convolution modules can be stacked in multiple layers in the network to achieve deep modeling and fusion of multi-path structural information.

[0148] Step S4.4: Vulnerability detection. After multi-layer graph convolution, the node representation The graph representation is obtained through graph-level aggregation operation, generating a graph-level representation:

[0149]

[0150] in, Represents the total number of basic block nodes in the graph. Finally, through a layer of fully connected mapping and using the Sigmoid activation function, the predicted vulnerability probability is output:

[0151]

[0152] in, is the predicted vulnerability probability. During the model training phase, Binary Cross Entropy (BCE) is used as the optimization objective to measure the deviation between the predicted result and the true label.

[0153] This method enables effective smart contract vulnerability detection. We compare the proposed approach with a variety of representative vulnerability detection methods from three categories: traditional symbolic execution tools, homogeneous graph neural network models, and heterogeneous graph neural network models. The results are shown in Table 1.

[0154] Table 1 Comparison of test results of different detection methods

[0155]

[0156] The proposed method significantly outperforms traditional tools and isomorphic graph models in seven vulnerability detection tasks, achieving optimal performance on all vulnerability types, with F1 score improvements of 2.5%–11.9%.

[0157] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph, characterized by: Follow these steps: Step S1, constructing a control-data contract heterogeneous graph: Parse the contract bytecode to be tested into opcodes, and construct a heterogeneous control flow graph HCFG with basic blocks as nodes based on the opcode sequence. On the basis of constructing the block-level control flow graph, further model the data dependency relationship between basic blocks, construct multi-level data dependency, and finally obtain a control-data heterogeneous graph. ,The control-data heterogeneous graph consists of a vertex set V and an edge set E, τ:V→A is the node type mapping function, φ:E→R is the edge type mapping function, where A and R represent the node type set and edge type set respectively, A≥2.R>1; Step S2, multi-attribute static feature fusion: Analyze the heterogeneous graph, calculate the static attributes of each block node in the graph, and construct a multi-dimensional basic block feature vector; Step S3, graph embedding process: vectorize the multimodal information of the basic block nodes in the heterogeneous graph, and finally concatenate the three types of feature vectors to form an initial node embedding vector containing structural, semantic and execution features; Step S4: Design a feature-weighted graph convolutional network: Use node static properties to adaptively adjust the feature weights of control flow and data flow, model the semantic contributions of multiple types of edges through the graph attention mechanism, and finally generate the overall representation of the contract through graph-level aggregation. The vulnerability detection probability is output through the fully connected layer and Sigmoid function.

2. The smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph according to claim 1 is characterized by: The specific process of constructing the control-data contract heterogeneous graph in step S1 is as follows: Step S1.1: Take the EVM smart contract bytecode as input, parse it to generate an instruction sequence containing opcodes and their byte offsets, and use it to construct a heterogeneous graph. Step S1.2: Construct the opcode sequence into a control flow graph with basic blocks as nodes, and define different types of basic blocks according to their functions and roles in the control flow, thereby constructing a heterogeneous control flow graph; Step S1.3: Based on the heterogeneous control flow graph, capture the data flow relationship established between basic blocks through data entities and model the data dependency relationship between blocks; Step S1.4: Traverse the opcode sequence in each basic block, construct a data dependency subgraph within the basic block, and characterize the relationship between opcodes within the block in a fine-grained manner; Step S1.5: Combine the heterogeneous control flow graph with data dependency information to construct inter-block data flow edges and intra-block data dependency subgraphs, and finally obtain a control-data heterogeneous graph.

3. The smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph according to claim 2 is characterized by: Parsing the bytecode into the opcode in step S1.1 includes: Split the continuous hexadecimal string into bytes in groups of two characters, and then map each byte to the corresponding EVM opcode instruction through a table lookup. For instructions that require immediate parameters, read the corresponding bytes after the opcode as parameters and combine them into values, generating a linear instruction sequence with the original bytecode offset in sequence.

4. The smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph according to claim 3 is characterized by: The step S1.2 of constructing a heterogeneous control flow graph with basic blocks as nodes includes: Traverse the opcode sequence and identify the longest continuous opcode sequence between the jump target and the jump instruction as a basic block. Each basic block is uniquely identified by the byte offset of the first opcode. Based on the functions and roles of basic blocks in the control flow, the ENTRY, EXIT, COMMON, DISPATCHER, and FALLBACK node types are defined. ENTRY and EXIT represent the entry and exit of the control flow graph, respectively. A COMMON block is a sequence of opcodes located between the jump target and the jump instruction and executed in sequence, constituting the basic execution unit of the CFG. A DISPATCHE block is a COMMON block whose last instruction is RETURN or STOP, used to implement function distribution logic. A FALLBACK block is a separately defined DISPATCHER block that does not rely on call data during execution and does not contain any hash matching logic for function selection. Execution is terminated by the REVERT instruction, and it is used to handle the default behavior of unmatched function calls. Construct directed edges based on the control transfer relationship between basic blocks to form a control flow graph; By assigning opcode sequence characteristics or static execution properties to different types of nodes and edges, a heterogeneous control flow graph can be constructed that can reflect the program execution logic and structural characteristics.

5. The smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph according to claim 4 is characterized by: The step S1.3 of establishing data dependencies between modules includes: Step S1.3.1, traverse the basic block nodes in the control flow graph using a depth-first search strategy, and perform dependency analysis on the opcode sequence within each basic block in order; Step S1.3.2: Use a virtual stack to simulate the access pattern of each opcode instruction to the stack, memory, and stored data entities, and record the data dependencies caused by read and write behaviors between opcodes; Step S1.3.3: Based on the data interaction behavior, construct an opcode-level data dependency list to clarify the data flow relationship between instructions; Step S1.3.4: Dependence on the EVM global state, introducing a virtual global block node GLOBAL as a unified source of external data; Step S1.3.5: Aggregate the opcode-level dependencies within the same basic block and map them into data flow edges between basic blocks.

6. The smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph according to claim 5 is characterized by: Step S1.4 constructs the intra-block data dependency subgraph including: For each opcode instruction sequence opcodes in a basic block, a data dependency edge set is constructed to form a complete intra-block data dependency subgraph; The data dependency edge set E is dynamically generated during the traversal of the opcode instruction sequence. If an element pushed into the stack by opcode A is referenced or consumed by opcode B, a directed edge e from A to B is added, indicating that the result of opcode A affects opcode B. When opcode B uses these elements, the consumed elements are removed from the current stack, memory, or storage structure, and the newly pushed elements record the position of the current opcode; Finally, the dependency edges are summarized to obtain the complete intra-block data dependency edge set E.

7. The smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph according to claim 6 is characterized by: The step S2 of multi-attribute static feature fusion includes: Step S2.1 calculates the dominator tree depth of the node The dominance relationship is defined as follows: Heterogeneous graph For any two nodes , from the entry node To Node All paths must pass through the node , then it is called a node Dominant Node , recorded as The dominance relationship among all nodes constitutes a tree with the entry node The directed tree with root is the dominating tree, and the depth of the dominating tree is The calculation formula is as follows: ； Among them, represents the node The parent node in the document tree; Step S2.2 calculates the PageRank centrality of each node Given a heterogeneous graph , any node PageRank value It is obtained through iterative calculation. Specifically, in the iterative initialization phase, the PageRank of all nodes is set to , is the total number of nodes. As the iteration proceeds, the PageRank of each node is continuously updated. of The calculation formula is as follows: ； in, is the damping factor, For nodes The set of predecessor nodes; Representation node The out-degree of For a basic block node ,in Represents a single opcode in the instruction set executed sequentially within the basic block. In order to quantify the static execution cost of the basic block, the function is defined To represent the operation code Static Gas cost; Based on the above definition, the basic block Total Gas consumption It can be calculated by summing the gas costs of all opcodes in a basic block, as follows: ； When the PageRank value change of all nodes in two adjacent iterations is lower than the preset convergence threshold , or when the specified maximum number of iterations is reached, the calculation process terminates and the final result is That is the node The PageRank centrality score of Step S2.3 Calculate the Gas consumption of each block node For one Basic block node ,in Represents a single opcode in the instruction set executed sequentially within the basic block. In order to quantify the static execution cost of the basic block, the function is defined To represent the operation code Static Gas cost; Based on the above definition, the basic block The total gas consumption Gas() can be calculated by summing the gas costs of all opcodes within the basic block, using the following formula: ； Step S2.4 combines the three numerical values ​​of dominance tree depth, PageRank value, and Gas consumption with the block type to form a multi-dimensional static feature.

8. The smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph according to claim 7 is characterized by: The graph embedding process in step S3 includes: Step S3.1: The opcode sequence is mapped into a fixed-length vector using the pre-trained Word2Vec model and average pooled to generate the overall representation. Step S3.2: For the intra-block data dependency subgraph, the edge vector of each edge is generated by the Hadamard product of the node vectors at both ends, and then the subgraph representation is obtained by average pooling; Step S3.3: Static attributes include block node type, dominator tree depth, gas consumption, and PageRank centrality. Block node type is represented by one-hot encoding. The latter three numerical attributes are normalized and concatenated with the block type vector to form a static feature vector representation. Step S3.4: Finally, the three types of feature vectors, namely, the opcode sequence, the data dependency subgraph, and the static attribute, are concatenated to form the initial embedding vector of the node, which serves as the input basis of the graph convolutional network.

9. The smart contract vulnerability detection method based on a multi-level data dependency heterogeneous graph according to claim 8 is characterized by: The step S4 of designing a feature weight relationship graph convolutional network includes: Step S4.1, dynamically adjust the control flow and data flow feature weights using node static attributes; The initial representation of each basic block node is as follows: ； in, is the opcode sequence embedded in the control flow, is the edge vector aggregation representation of the data dependency subgraph, Represents a static attribute vector, using static attribute features Dynamically generate attention weights: ； in, As a learnable parameter, the generated attention weight is used to weightedly fuse the control and data path features to form the updated node features: ； Step S4.2: Adaptively model the semantic contributions of multiple types of edges through the graph attention mechanism; The FW-RGCN feature weight relation graph convolutional network introduces a relational perception mechanism in the graph convolution process, For any side type , the model learns an independent linear mapping for it: ； A multi-head attention mechanism is used to aggregate information between nodes. The attention weight is calculated as follows: ； in, Indicates the edge type The set of adjacent nodes under is the attention vector, Represents the splicing operation, which uses weighted summation to aggregate neighbor information and splice the output of all heads, and updates the node representation through nonlinear activation: ； ； in, and The above convolution modules can be stacked in multiple layers in the network to achieve deep modeling and fusion of multi-path structural information. Step S4.3: Input the feature learning results into the fully connected layer and the Sigmoid layer to obtain the probability of various vulnerabilities existing in the smart contract to be tested. Vulnerabilities with probabilities greater than the set value are regarded as the most likely vulnerabilities in the smart contract to be tested. After multi-layer graph convolution, the node representation The graph representation is obtained through graph-level aggregation operation, generating a graph-level representation: ； in, Represents the total number of basic block nodes in the graph. Finally, it passes through a fully connected mapping layer and uses the Sigmoid activation function to output the predicted vulnerability probability: ； in, In order to predict the vulnerability probability, binary cross entropy is used as the optimization target in the model training phase to measure the deviation between the predicted results and the true labels.

Images