A smart contract bytecode similarity detection method based on graph neural network

Abstract

The present invention discloses a method for detecting the similarity of smart contract bytecodes based on a graph neural network, comprising: disassembling the bytecode of the Ethereum virtual machine, performing data flow analysis and control flow analysis on the disassembly result, and obtaining a data flow graph and a control flow graph corresponding to the bytecode; combining the data flow graph and the control flow graph of each external function into a bytecode feature graph; training the graph neural network using a large number of smart contracts with similar labels, performing vectorization operations on the bytecode feature graph during the training process to obtain a feature vector; using the problem contract as a reference smart contract, inputting the bytecode feature graphs of the reference smart contract and the smart contract to be detected into the trained graph neural network respectively, obtaining corresponding feature vectors respectively, comparing the Euclidean distance of the two feature vectors, and measuring the similarity of the bytecodes of the two smart contracts. Compared with traditional methods, the present invention has higher accuracy, can effectively identify problem contracts, and enhance the security of the blockchain system.

Description

Technical Field

[0001] The present invention relates to the field of computer networks, and in particular to a method for detecting similarity of smart contract bytecodes based on graph neural networks. Background Art

[0002] In today's computer network technology landscape, with the rapid development of blockchain technology, smart contracts have become a crucial tool for implementing decentralized applications (DApps). A smart contract is a self-executing contract running on a blockchain. Its logic is programmed on the blockchain, automatically executing predetermined conditions. However, with the widespread use of smart contracts, their security concerns are becoming increasingly prominent, particularly regarding vulnerabilities and malicious contracts.

[0003] Smart contracts are typically written in a high-level language, compiled into a blockchain-specific bytecode format, and deployed on the blockchain. Since bytecode is the actual execution format of smart contracts on the blockchain, analyzing bytecode similarities is a key approach to identifying and analyzing smart contract security. For example, by comparing the bytecode of an unknown smart contract with the bytecode of a known malicious contract, potentially malicious contracts can be effectively identified. Alternatively, by analyzing the behavior of similar smart contracts, developers can avoid common programming errors and vulnerabilities.

[0004] Currently, similarity detection of smart contract bytecodes primarily relies on traditional code similarity analysis techniques, such as hash-based methods, text comparison-based methods, and methods based solely on control flow graphs. While these methods can detect similarity to a certain extent, they often struggle to accurately reflect the deep-level similarities between bytecodes given the complex contract logic and dynamic execution characteristics. This is especially true when dealing with highly optimized bytecodes or bytecodes compiled using different compilers. Summary of the Invention

[0005] In response to the shortcomings of the existing technology, the present invention proposes a smart contract bytecode similarity detection method based on graph neural network. This method can effectively utilize the structural information of the bytecode and deeply analyze the semantic similarity of the bytecode through graph neural network to improve the accuracy and efficiency of detection.

[0006] The specific technical solutions are as follows:

[0007] A method for detecting smart contract bytecode similarity based on graph neural network, comprising the following steps:

[0008] Step 1: Disassemble the Ethereum virtual machine bytecode to generate disassembled code;

[0009] Step 2: Perform data flow analysis and control flow analysis on the disassembly result to obtain the data flow graph and control flow graph corresponding to the bytecode; this is achieved through the following sub-steps:

[0010] (2.1) Maintain a control flow graph entry and a symbolic execution stack for each external function of the smart contract;

[0011] (2.2) Use instructions to divide each external function into multiple basic blocks arranged in sequence, and all instructions in each basic block are executed sequentially; the control flow set corresponding to each external function is obtained to obtain a control flow graph;

[0012] (2.3) When an instruction is executed, the data popped from the stack by the instruction is the data used by the instruction, and the data pushed into the stack by the instruction is the data defined by the instruction. If the data used by an instruction comes from the data defined by another instruction, a directed edge from the data defined by the instruction to the data used by the instruction is added to the data flow graph.

[0013] Step 3: Combine the data flow graph and control flow graph of each external function into a bytecode feature graph;

[0014] Step 4: A training dataset is obtained by collecting bytecode feature graphs obtained from steps 1 to 3 for a large number of smart contracts with similar labels. The training dataset is used to train the graph neural network. During the training process, the graph neural network vectorizes the bytecode feature graphs to obtain bytecode feature vectors.

[0015] Step 5: Use the problem contract as the reference smart contract and use the methods from Steps 1 to 3 to obtain the bytecode feature graphs of the reference smart contract and the smart contract to be tested. Then, input them into the trained graph neural network to obtain the feature vector of the reference smart contract and the feature vector of the smart contract to be tested. Compare the Euclidean distance between the feature vector of the smart contract to be tested and the feature vector of the reference smart contract to measure the similarity of the bytecodes of the two smart contracts.

[0016] Furthermore, in step (2.2), the control flow corresponding to each external function is obtained through the following sub-steps:

[0017] (2.2.1) Initializing a first recursive stack, which contains only an empty symbolic execution stack and the first basic block arranged starting from the entry of the control flow graph corresponding to the external function;

[0018] (2.2.2) Pop the basic block at the top of the first recursion stack and record it as the current block. Pop the symbolic execution stack and execute the instructions in the current block sequentially on the symbolic execution stack.

[0019] (2.2.3) Determine what operation is performed when the current block reaches the last instruction. Depending on the last instruction, there are three situations:

[0020] Case 1: The last instruction of the current block is a JUMP instruction. The data, i.e., the target address, is retrieved from the top of the symbolic execution stack. The basic block pointed to by the target address is the top block of the symbolic stack. A determination is made as to whether there is a directed edge from the current block to the top block of the symbolic stack in the control flow graph. If not, the top block of the symbolic stack and the current symbolic execution stack are added as a whole to the top of the first recursive stack. A directed edge from the current block to the top block of the symbolic stack is also added to the control flow graph, and step (2.2.4) is then executed. Otherwise, step (2.2.4) is executed directly.

[0021] Case 2: The last instruction of the current block is the JUMPI instruction; at this time, both the satisfied and unsatisfied conditions are executed at the same time;

[0022] If the judgment condition is not met, determine whether the directed edge from the current block to the next basic block in the arrangement order is in the control flow graph. If not, add the next basic block and the current symbolic execution stack as a whole to the top of the first recursive stack, add the directed edge from the current block to the next basic block in the control flow graph, and then execute step (2.2.4). If yes, execute step (2.2.4) directly.

[0023] For cases where the judgment conditions are met, the execution operation is the same as in case 1;

[0024] Case 3: The last instruction of the current block is other than JUMP and JUMPI. In this case, execute step (2.2.4) directly.

[0025] (2.2.4) Determine whether the first recursive stack is empty. If so, end the generation of this control flow; if not, repeat steps (2.2.2)-(2.2.3).

[0026] Furthermore, in step 3, the basic blocks in the control flow graph are traversed, and for each basic block, recursion and bytecode feature graph generation operations are performed simultaneously;

[0027] The recursion is implemented through the following sub-steps:

[0028] (3.1.1) Initialize the second recursion stack, which only contains the current basic block and an empty instruction set;

[0029] (3.1.2) Determine whether the second recursive stack is empty. If so, return to the instruction set and jump to step (3.2.1); if not, execute step (3.1.3);

[0030] (3.1.3) Pop the basic block at the top of the second recursive stack, traverse the predecessor blocks of this basic block in the control flow graph, and obtain the key instruction of each predecessor block; if a predecessor block b does not have a key instruction, execute step (3.1.4); if predecessor block b does have a key instruction, add the last key instruction of predecessor block b to the instruction set and return to step (3.1.2);

[0031] (3.1.4) Determine whether the predecessor block b has been accessed. If not, add all predecessor blocks of the predecessor block b in the control flow graph to the top of the second recursive stack and return to step (3.1.2); if so, directly return to step (3.1.2);

[0032] Generating the bytecode feature map is specifically implemented through the following operations, and there is no execution order requirement for the three sub-steps;

[0033] (3.2.1) Obtain all key instructions in the current basic block, and add all directed edges connecting all key instructions in the instruction set with the first key instruction in the current basic block to the bytecode feature graph;

[0034] (3.2.2) Obtain all key instructions in the current basic block, add the directed edge connecting the nth and n+1th key instructions to the bytecode feature graph, where n = 1, 2, ..., N-1, where N is the total number of key instructions in the current basic block;

[0035] (3.2.3) Traverse all key instructions in the current basic block. For each key instruction, traverse all data defined by the key instruction in the data flow graph. These data are called definition data. Add all directed edges connecting the key instruction and each definition data to the bytecode feature graph, and add all directed edges pointing to each definition data in the data flow graph to the bytecode feature graph.

[0036] Furthermore, the key instructions include: storage instructions, log instructions, external call instructions, and control flow termination instructions;

[0037] The storage instructions include: SSTORE, SLOAD;

[0038] The log instructions include: LOG0, LOG1, LOG2, LOG3, LOG4;

[0039] The external call instructions include: CALL, STATICCALL, DELEGATECALL;

[0040] The control flow termination instructions include: RETURN, SELFDESTRUCT, REVERT, TROW, and STOP.

[0041] Furthermore, in step 1, the bytecode is mapped through the instruction table of the Ethereum virtual machine, and irrelevant data is deleted according to the compilation rules of the Solc compiler; the irrelevant data includes compiler metadata.

[0042] Furthermore, in step (2.1), for each control flow graph entry of an external function, a fixed comparison-jump pattern is followed: the user passes a parameter to the smart contract, and the smart contract compares the first four bytes of the parameter with the selector corresponding to each external function in turn. If they match, it jumps to the entry corresponding to the external function; otherwise, it continues to compare the selector corresponding to the next external function; if the first four bytes of the parameter do not match the selector of any external function, it jumps to the entry of the fallback function.

[0043] Furthermore, in the step (2.2), each external function is divided into a plurality of basic blocks arranged in sequence using instructions, wherein the instructions include: a jump instruction JUMP, a conditional jump instruction JUMPI, a jump target instruction JUMPDEST, a rollback instruction REVERT, a stop instruction STOP, a return instruction RETURN, a self-destruct instruction SELFDESTRUCT, and a throw error instruction TROW.

[0044] The beneficial effects of the present invention are:

[0045] (1) The present invention introduces control flow features and data flow features simultaneously in the problem of detecting the similarity of smart contract bytecodes, and combines them to form a bytecode feature graph, so that the similarity comparison has a stronger ability to resist optimization and compiler upgrades, thereby improving the accuracy of detecting smart contract bytecodes.

[0046] (2) By introducing a graph neural network to directly process and analyze the bytecode structure and semantic features of smart contracts, the proposed method significantly improves the accuracy and efficiency of bytecode similarity detection. Compared with traditional methods, the proposed method can provide a deeper understanding of the execution logic and behavior patterns of smart contracts, thereby enhancing the security analysis capabilities of blockchain applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 This is a flowchart of a method for detecting similarity of smart contract bytecodes based on a graph neural network in an embodiment of the present invention.

[0048] Figure 2 This is a flow chart of a method for generating a control flow corresponding to each external function in step 2 of an embodiment of the present invention.

[0049] Figure 3 It is a flow chart of the method for combining the data flow graph and control flow graph corresponding to each external function into a bytecode feature graph in step three of an embodiment of the present invention. DETAILED DESCRIPTION

[0050] The present invention will be described in detail below based on the accompanying drawings and preferred embodiments. The purpose and effects of the present invention will become more apparent. The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.

[0051] A smart contract bytecode similarity detection method based on graph neural network, such as Figure 1 As shown, the specific steps include:

[0052] Step 1: Disassemble the Ethereum Virtual Machine bytecode to generate disassembled code. Specifically, the bytecode is mapped using the Ethereum Virtual Machine's instruction table, and irrelevant data (such as compiler metadata) is deleted according to the Solc compiler's compilation rules to obtain the disassembled code.

[0053] Step 2: Perform data flow analysis and control flow analysis on the disassembly result to obtain the data flow graph and control flow graph corresponding to the bytecode. This is achieved through the following sub-steps, where data flow analysis and control flow analysis (i.e., steps (2.3) and (2.2)) can be performed simultaneously.

[0054] (2.1) Maintain a control flow graph entry and a symbolic execution stack for each external function of the smart contract. The symbolic execution stack is a stack data structure that stores symbolic values. Symbolic values ​​include numerical values ​​and unknown values. When instruction execution requires values ​​such as storage and user parameters, these values ​​can be replaced with unknown values, and constant values ​​can be used when constants are needed. Using the symbolic execution stack can replace the Ethereum Virtual Machine stack and facilitate the construction of the control flow graph.

[0055] The disassembly result itself does not contain external function information, but the Solc compiler has a fixed compilation mode for external function entries. Therefore, for each external function's control flow graph entry, it follows a fixed comparison-jump pattern. That is, the user passes a parameter to the smart contract, and the smart contract compares the first four bytes of the parameter with the selector corresponding to each external function in turn. If there is a match, it jumps to the entry corresponding to that external function. Otherwise, it continues to compare the selector corresponding to the next external function. If the first four bytes of the parameter do not match any external function selector, it jumps to the entry of the fallback external function.

[0056] (2.2) Use JUMP (jump instruction), JUMPI (conditional jump instruction), JUMPDEST (jump target instruction), REVERT (return instruction), STOP (stop instruction), RETURN (return instruction), SELFDESTRUCT (self-destruct instruction), and THROW (throw error instruction) as boundaries to divide each external function into multiple basic blocks arranged in sequence. All instructions in each basic block must be executed in sequence.

[0057] For each external function, the control flow starts from the entry and extends according to the rules, such as Figure 2 As shown, the specific steps include:

[0058] (2.2.1) Initialize a first recursive stack, which only contains an empty symbolic execution stack and the first basic block arranged starting from the control flow graph entry corresponding to the external function.

[0059] (2.2.2) The basic block at the top of the first recursive stack (called the current block) and the symbolic execution stack are popped out, and the instructions in the current block are executed sequentially on the symbolic execution stack. During this process, the symbolic execution stack is updated.

[0060] (2.2.3) Determine what operation is performed when the current block reaches the last instruction. Depending on the last instruction, there are three situations:

[0061] Case 1: The last instruction of the current block is a JUMP instruction. The data, i.e., the target address, is retrieved from the top of the symbolic execution stack. The target address points to a basic block (called the top block of the symbolic stack). Determine whether there is a directed edge in the control flow graph from the current block to the top block of the symbolic stack. If not, add the top block of the symbolic stack and the current symbolic execution stack as a whole to the top of the first recursive stack, add a directed edge from the current block to the top block of the symbolic stack to the control flow graph, and then execute step (2.2.4). Otherwise, execute step (2.2.4) directly.

[0062] Case 2: The last instruction of the current block is a JUMPI instruction. In this case, both the cases where the jump condition is met and the cases where the jump condition is not met need to be executed simultaneously.

[0063] For cases where the jump condition is not met, determine whether the directed edge from the current block to the next basic block in the arrangement order is in the control flow graph. If not, add the next basic block and the current symbolic execution stack as a whole to the top of the first recursive stack, and add the directed edge from the current block to the next basic block in the control flow graph, and then execute step (2.2.4); if so, execute step (2.2.4) directly.

[0064] If the jump condition is met, the target address is retrieved from the top of the symbolic execution stack. The basic block pointed to by this target address is called the top block of the symbolic stack. Next, a determination is made as to whether there is a directed edge in the control flow graph from the current block to the top block of the symbolic stack. If not, the top block of the symbolic stack and the current symbolic execution stack are added as a whole to the top of the first recursive stack. A directed edge from the current block to the top block of the symbolic stack is also added to the control flow graph, and step (2.2.4) is executed again. Otherwise, step (2.2.4) is executed directly.

[0065] Case 3: The last instruction of the current block is any instruction other than JUMP and JUMPI. In this case, execute step (2.2.4) directly.

[0066] (2.2.4) Determine whether the first recursive stack is empty. If so, end the generation of this control flow; if not, repeat steps (2.2.2)-(2.2.3).

[0067] (2.3) When an instruction is executed, it pops data from the stack and pushes data onto the stack. The data popped from the stack is the data used by the instruction, and the data pushed onto the stack is the data defined by the instruction. If the data used by an instruction comes from data defined by another instruction, a directed edge from the data defined by the instruction to the data used by the instruction is added to the data flow graph.

[0068] Step 3: Combine the data flow graph and control flow graph of each external function into a bytecode feature graph. Figure 3 As shown, the basic blocks in the control flow graph are traversed, and for each basic block, recursion and bytecode feature graph generation are performed simultaneously:

[0069] (3.1) Recursion is implemented through the following sub-steps:

[0070] (3.1.1) Initialize a second recursion stack, which only contains the current basic block, and initialize an empty instruction set.

[0071] (3.1.2) Determine whether the second recursive stack is empty. If so, return to the instruction set and jump to step (3.2.1); if not, execute step (3.1.3).

[0072] (3.1.3) Pop the basic block at the top of the second recursive stack, traverse the predecessor blocks of the basic block in the control flow graph, and obtain the key instructions of each predecessor block; if there is no key instruction in a predecessor block b, execute step (3.1.4); if there is a key instruction in the predecessor block b, add the last key instruction of the predecessor block b to the instruction set and return to step (3.1.2).

[0073] The key instructions mentioned above include: storage instructions, log instructions, external call instructions, and control flow termination instructions. These instructions are instructions for smart contracts to change the state of the blockchain world or control flow termination instructions. The control and data relationships between them represent the semantics of smart contracts.

[0074] Specifically, the storage instructions include: SSTORE and SLOAD.

[0075] Log instructions include: LOG0, LOG1, LOG2, LOG3, LOG4.

[0076] External call instructions include: CALL, STATICCALL, DELEGATECALL.

[0077] Control flow termination instructions include: RETURN, SELFDESTRUCT, REVERT, TROW, and STOP.

[0078] (3.1.4) Determine whether the predecessor block b has been accessed. If not, add all the predecessor blocks of the predecessor block b in the control flow graph to the top of the second recursive stack and return to step (3.1.2); if so, return directly to step (3.1.2).

[0079] (3.2) Generate a bytecode feature map, which is specifically achieved through the following operations. There is no execution order requirement for the three sub-steps.

[0080] (3.2.1) Obtain all key instructions in the current basic block, and add all directed edges connecting all key instructions in the instruction set and the first key instruction in the current basic block to the bytecode feature graph.

[0081] (3.2.2) Obtain all key instructions in the current basic block, and add the directed edge connecting the nth and n+1th key instructions to the bytecode feature graph, where n = 1, 2, ..., N-1, where N is the total number of key instructions in the current basic block.

[0082] (3.2.3) Traverse all key instructions in the current basic block. For each key instruction, traverse all data defined by the key instruction in the data flow graph (hereinafter referred to as definition data), add all directed edges connecting the key instruction and each definition data to the bytecode feature graph, and add all directed edges pointing to each definition data in the data flow graph to the bytecode feature graph.

[0083] Step 4: Use the set of bytecode feature graphs obtained from a large number of smart contracts with similar labels through the methods of steps 1 to 3 as a training dataset to train the Graph Neural Network (GNN). During the training process, GNN vectorizes the bytecode feature graphs to obtain the bytecode feature vectors.

[0084] Step 5: Use the problematic contract as the reference smart contract. The bytecode feature maps generated using steps 1 through 3 for both the reference smart contract and the smart contract to be tested are fed into the trained GNN to obtain the feature vector of the reference smart contract. The Euclidean distance between the feature vector of the smart contract to be tested and the feature vector of the reference smart contract is then compared to measure the similarity between the bytecodes of the two smart contracts. The smaller the Euclidean distance, the higher the similarity.

[0085] The following example further demonstrates the effectiveness of the method of the present invention. Using the method of the present invention to perform similarity testing on 14,286 similar contract pairs, the experiment demonstrates that the method of the present invention can achieve an AUC (Area Under the Curve) value of 0.963, far exceeding the results achieved by traditional methods.

[0086] Those skilled in the art will understand that the foregoing descriptions are merely preferred embodiments of the invention and are not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art will still be able to modify the technical solutions described in the foregoing examples or substitute equivalents for some of the technical features therein. Any modifications, equivalent substitutions, etc. made within the spirit and principles of the invention shall be included within the scope of protection of the invention.

Claims

1. A method for detecting smart contract bytecode similarity based on graph neural network, characterized in that: The following steps are involved: Step 1: Disassemble the Ethereum virtual machine bytecode to generate disassembled code; Step 2: Perform data flow analysis and control flow analysis on the disassembly result to obtain the data flow graph and control flow graph corresponding to the bytecode; this is achieved through the following sub-steps: (2.1) Maintain a control flow graph entry and a symbolic execution stack for each external function of the smart contract; (2.2) Use instructions to divide each external function into multiple basic blocks arranged in sequence. All instructions in each basic block are executed sequentially. The control flow set corresponding to each external function is used to obtain a control flow graph. (2.3) When an instruction is executed, the data popped from the stack by the instruction is the data used by the instruction, and the data pushed onto the stack by the instruction is the data defined by the instruction. If the data used by an instruction comes from the data defined by another instruction, a directed edge from the data defined by the instruction to the data used by the instruction is added to the data flow graph. Step 3: Combine the data flow graph and control flow graph of each external function into a bytecode feature graph; In the step 3, the basic blocks in the control flow graph are traversed, and for each basic block, recursion and bytecode feature graph generation are performed simultaneously; The recursion is implemented through the following sub-steps: (3.1.1) Initialize the second recursion stack, which only contains the current basic block and an empty instruction set; (3.1.2) Determine whether the second recursive stack is empty. If so, return to the instruction set and jump to step (3.2.1). If not, execute step (3.1.3). (3.1.3) Pop the basic block at the top of the second recursive stack, traverse the predecessor blocks of this basic block in the control flow graph, and obtain the key instruction of each predecessor block; if a predecessor block b does not have a key instruction, execute step (3.1.4); if predecessor block b does have a key instruction, add the last key instruction of predecessor block b to the instruction set and return to step (3.1.2); (3.1.4) Determine whether the predecessor block b has been accessed. If not, add all predecessor blocks of the predecessor block b in the control flow graph to the top of the second recursive stack and return to step (3.1.2). If yes, return directly to step (3.1.2). Generating the bytecode feature map is specifically implemented through the following operations, and there is no execution order requirement for the three sub-steps; (3.2.1) Obtain all key instructions in the current basic block, and add all directed edges connecting all key instructions in the instruction set with the first key instruction in the current basic block to the bytecode feature graph; (3.2.2) Obtain all key instructions in the current basic block and add the directed edge connecting the nth and n+1th key instructions to the bytecode feature graph, where n = 1, 2, …, N-1, where N is the total number of key instructions in the current basic block. (3.2.3) Traverse all key instructions in the current basic block. For each key instruction, traverse all data defined by the key instruction in the data flow graph. These data are called definition data. Add all directed edges connecting the key instruction and each definition data to the bytecode feature graph. Also, add all directed edges in the data flow graph pointing to each definition data to the bytecode feature graph. Step 4: A training dataset is obtained by collecting the bytecode feature graphs obtained from steps 1 to 3 for a large number of smart contracts with similar labels. The training dataset is used to train the graph neural network. During the training process, the graph neural network vectorizes the bytecode feature graphs to obtain the bytecode feature vectors. Step 5: Use the problem contract as the reference smart contract and use the methods from Steps 1 to 3 to obtain the bytecode feature graphs of the reference smart contract and the smart contract to be tested. Then, input them into the trained graph neural network to obtain the feature vector of the reference smart contract and the feature vector of the smart contract to be tested. Compare the Euclidean distance between the feature vector of the smart contract to be tested and the feature vector of the reference smart contract to measure the similarity of the bytecodes of the two smart contracts.

2. The method for detecting smart contract bytecode similarity based on graph neural network according to claim 1 is characterized in that: In step (2.2), the control flow corresponding to each external function is obtained through the following sub-steps: (2.2.1) Initializing a first recursive stack, which contains only an empty symbolic execution stack and the first basic block arranged starting from the entry of the control flow graph corresponding to the external function; (2.2.2) Pop the basic block at the top of the first recursion stack and record it as the current block. Pop the symbolic execution stack and execute the instructions in the current block sequentially on the symbolic execution stack. (2.2.3) Determine what operation is performed when the current block reaches the last instruction. Depending on the last instruction, there are three situations: Case 1: The last instruction of the current block is a JUMP instruction. The data, i.e., the target address, is retrieved from the top of the symbolic execution stack. The basic block pointed to by the target address is the top block of the symbolic stack. A determination is made as to whether there is a directed edge from the current block to the top block of the symbolic stack in the control flow graph. If not, the top block of the symbolic stack and the current symbolic execution stack are added as a whole to the top of the first recursive stack. A directed edge from the current block to the top block of the symbolic stack is also added to the control flow graph, and step (2.2.4) is then executed. Otherwise, step (2.2.4) is executed directly. Case 2: The last instruction of the current block is the JUMPI instruction; at this time, both the satisfied and unsatisfied conditions are executed at the same time; If the judgment condition is not met, determine whether the directed edge from the current block to the next basic block in the arrangement order is in the control flow graph. If not, add the next basic block and the current symbolic execution stack as a whole to the top of the first recursive stack, add the directed edge from the current block to the next basic block in the control flow graph, and then execute step (2.2.4). If yes, execute step (2.2.4) directly. For cases where the judgment conditions are met, the execution operation is the same as in case 1; Case 3: The last instruction of the current block is any instruction other than JUMP and JUMPI. In this case, execute step (2.2.4) directly. (2.2.4) Determine whether the first recursive stack is empty. If so, end the generation of this control flow; if not, repeat steps (2.2.2)-(2.2.3).

3. The method for detecting smart contract bytecode similarity based on graph neural network according to claim 1 is characterized in that: The key instructions include: storage instructions, log instructions, external call instructions, and control flow termination instructions; The storage instructions include: SSTORE, SLOAD; The log instructions include: LOG0, LOG1, LOG2, LOG3, LOG4; The external call instructions include: CALL, STATICCALL, DELEGATECALL; The control flow termination instructions include: RETURN, SELFDESTRUCT, REVERT, TROW, and STOP.

4. The method for detecting smart contract bytecode similarity based on graph neural network according to claim 1, characterized in that: In step 1, the bytecode is mapped through the instruction table of the Ethereum virtual machine, and irrelevant data is deleted according to the compilation rules of the Solc compiler; the irrelevant data includes compiler metadata.

5. The method for detecting smart contract bytecode similarity based on graph neural network according to claim 1 is characterized in that: In step (2.1), for each control flow graph entry of an external function, a fixed comparison-jump pattern is followed: the user passes a parameter to the smart contract, and the smart contract compares the first four bytes of the parameter with the selector corresponding to each external function in turn. If a match is found, the smart contract jumps to the entry corresponding to the external function; otherwise, the smart contract continues to compare the selector corresponding to the next external function. If the first four bytes of the parameter do not match the selector of any external function, jump to the entry of the fallback function.

6. The method for detecting smart contract bytecode similarity based on graph neural network according to claim 1, characterized in that: In the step (2.2), each external function is divided into a plurality of basic blocks arranged in sequence using instructions, wherein the instructions include: a jump instruction JUMP, a conditional jump instruction JUMPI, a jump target instruction JUMPDEST, a rollback instruction REVERT, a stop instruction STOP, a return instruction RETURN, a self-destruct instruction SELFDESTRUCT, and a throw error instruction TROW.

Images