Intelligent contract byte code similarity detection method based on graph neural network

Abstract

The invention discloses a graph neural network-based intelligent contract bytecode similarity detection method, which comprises the following steps of: performing disassembling operation on Ethereum virtual machine bytecodes, and performing data flow analysis and control flow analysis on disassembling results to obtain a data flow graph and a control flow graph corresponding to the bytecodes; combining the data flow diagram and the control flow diagram of each external function into a byte code characteristic diagram; a large number of intelligent contracts with similar labels are adopted to train a graph neural network, vectorization operation is performed on the byte code feature graph in the training process, and feature vectors are obtained; and taking the problem contract as a reference smart contract, respectively inputting the bytecode feature maps of the reference smart contract and the to-be-detected smart contract into the trained graph neural network to respectively obtain corresponding feature vectors, comparing the Euclidean distance of the two feature vectors, and measuring to obtain the similarity of the bytecode of the two smart contracts. Compared with a traditional method, the method has higher accuracy, problem contracts can be effectively recognized, and the safety of a block chain system is enhanced.

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 field, with the rapid development of blockchain technology, smart contracts have become an important tool for realizing decentralized applications (DApp). Smart contracts are self-executing contracts that run on the blockchain. Their logic is written on the blockchain and can automatically execute predetermined conditions. However, with the widespread application of smart contracts, their security issues have become increasingly prominent, especially the vulnerabilities of smart contracts and malicious contracts.

[0003] Smart contracts are usually written in a high-level language and then compiled into a blockchain platform-specific bytecode format and deployed on the blockchain. Since bytecode is the form in which smart contracts are actually executed on the blockchain, analyzing the similarity of bytecodes has become a key way to identify and analyze the security of smart contracts. For example, by comparing the similarity between the bytecode of an unknown smart contract and the bytecode of a known malicious contract, potential malicious contracts can be effectively identified, or by analyzing the behavior of similar smart contracts, developers can be helped to avoid common programming errors and vulnerabilities.

[0004] At present, the similarity detection of smart contract bytecode mainly relies on traditional code similarity analysis techniques, such as hash-based methods, text comparison-based methods, control flow graph-based methods, etc. Although these methods can achieve similarity detection to a certain extent, in the face of complex contract logic and dynamic execution characteristics, these traditional methods are often difficult to accurately reflect the deep similarity between bytecodes, especially when dealing with highly optimized bytecodes or bytecodes compiled with different compilers. Summary of the invention

[0005] In view of the shortcomings of the prior art, the present invention proposes a smart contract bytecode similarity detection method based on graph neural network. The 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 detection accuracy and efficiency.

[0006] The specific technical solutions are as follows:

[0007] A method for detecting bytecode similarity of smart contracts based on graph neural network includes 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 executing an instruction, 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, then the 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 data set is obtained by collecting bytecode feature graphs obtained by the methods of steps 1 to 3 for a large number of smart contracts with similar labels. The training data set is used to train the graph neural network. During the training process, the graph neural network vectorizes the bytecode feature graph to obtain the feature vector of the bytecode.

[0015] Step 5: Take the problematic contract as the reference smart contract, and use the methods of step 1 to step 3 to obtain the bytecode feature graphs of the reference smart contract and the smart contract to be tested, respectively, and 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 the 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, wherein the first recursive stack only includes 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 recursive stack and record it as the current block, and 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 specific operation is performed when the current block executes 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; fetch data from the top of the symbolic execution stack, i.e., the target address, and the basic block pointed to by the target address is the top block of the symbolic stack; determine 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, 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, and add a directed edge from the current block to the top block of the symbolic stack in the control flow graph, and then execute step (2.2.4); otherwise, execute step (2.2.4) directly;

[0021] Case 2: The last instruction of the current block is the JUMPI instruction; at this time, the cases where the judgment condition is met and the cases where the judgment condition is not met are executed at the same time;

[0022] For the case where 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, 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 yes, directly execute step (2.2.4);

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

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

[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 the step 3, the basic blocks in the control flow graph are traversed, and for each basic block, the operations of recursion and generating a bytecode feature graph are performed simultaneously;

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

[0028] (3.1.1) Initializing a second recursive stack, wherein the second recursive stack 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 the basic block in the control flow graph, and obtain the key instructions of each predecessor block; if a predecessor block b does not have a key instruction, execute step (3.1.4); if the predecessor block b has a key instruction, add the last key instruction of the 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 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 yes, directly return to step (3.1.2);

[0032] Generating the bytecode feature graph 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 and 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, which 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 in the data flow graph pointing to each definition data 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, THROW, and STOP.

[0041] Furthermore, in the 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 the 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, and 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 THROW.

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

[0045] (1) The present invention introduces control flow features and data flow features simultaneously in 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) The method of the present invention introduces a graph neural network to directly process and analyze the bytecode structure and semantic features of smart contracts, significantly improving the accuracy and efficiency of bytecode similarity detection. Compared with traditional methods, the present invention can more deeply understand 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 It is a flowchart of a smart contract bytecode similarity detection method based on graph neural network in an embodiment of the present invention.

[0048] Figure 2 It 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 according to the accompanying drawings and preferred embodiments, and the purpose and effect of the present invention will become more clear. 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 used to explain 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 through the instruction table of the Ethereum virtual machine, and irrelevant data (such as compiler metadata) is deleted according to the compilation rules of the Solc compiler 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 specifically achieved through the following sub-steps, where the 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 the execution of instructions requires values ​​such as storage and user parameters, unknown values ​​can be used to replace these values. When constants are used, constant numerical values ​​can be used. The symbolic execution stack can replace the Ethereum virtual machine stack and help build the control flow graph.

[0055] The disassembly result itself does not have external function information, but the Solc compiler has a fixed compilation mode for external function entries. Therefore, for each control flow graph entry of an external function, the fixed comparison-jump mode is followed, that is, the user passes the 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 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 instruction (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 specific operation is performed when the current block executes 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. Take the data from the top of the symbolic execution stack, that is, the target address, which points to a basic block (called the top block of the symbolic stack). Determine 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, 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, and add a directed edge from the current block to the top block of the symbolic stack in 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 at the same time.

[0063] For the case 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 yes, execute step (2.2.4) directly.

[0064] If the jump condition is met, the target address is taken from the top of the symbolic execution stack. The basic block pointed to by the target address is called the top block of the symbolic stack. Then, it is determined 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 to the top of the first recursive stack as a whole, and a directed edge from the current block to the top block of the symbolic stack is added to the control flow graph, and then step (2.2.4) is executed; 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, step (2.2.4) is executed 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 executing an instruction, the instruction will pop data from the stack and then push data into the stack. The data popped from the stack is the data used by the instruction, and the data pushed into the stack is the data defined by the instruction. If the data used by an instruction comes from the data defined by another instruction, then add the directed edge from the data defined by the instruction to the data used by the instruction 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 operations are performed simultaneously:

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

[0070] (3.1.1) Initialize a second recursive 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 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 a predecessor block b does not have a key instruction, execute step (3.1.4); if the predecessor block b has a key instruction, 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 relationship and data relationship between them can represent the semantics of smart contracts.

[0074] Specifically, storage instructions include: SSTORE, 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, THROW, 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 implemented through the following operations, and 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 in the data flow graph pointing to each definition data to the bytecode feature graph.

[0083] Step 4: Take a large number of smart contracts with similar labels and obtain a set of bytecode feature graphs through the methods of steps 1 to 3 as a training data set to train the Graph Neural Network (GNN). During the training process, GNN performs vectorization operations on the bytecode feature graph to obtain the feature vector of the bytecode.

[0084] Step 5: Take the problem contract as the reference smart contract, and input the bytecode feature graphs obtained by the methods of steps 1 to 3 for the reference smart contract and the smart contract to be tested into the trained GNN to obtain the feature vector of the reference smart contract. Then 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. The smaller the Euclidean distance, the higher the similarity.

[0085] The effect of the method of the present invention is further verified by an example. The method of the present invention is used to perform similarity detection on 14,286 similar contract pairs. Experiments show that the method of the present invention can achieve an AUC (area under the curve) value of 0.963, which is much higher than the effect achieved by traditional methods.

[0086] Those skilled in the art can understand that the above are only preferred examples of the invention and are not intended to limit the invention. Although the invention is described in detail with reference to the above examples, those skilled in the art can still modify the technical solutions recorded in the above examples or replace some of the technical features therein with equivalents. Any modification, equivalent replacement, etc. made within the spirit and principle of the invention shall be included in the protection scope of the invention.

Claims

1. A method for detecting bytecode similarity of smart contracts 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, 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; (2.3) When executing an instruction, 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, then the 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; Step 4: A training data set is obtained by collecting bytecode feature graphs obtained by the methods of steps 1 to 3 for a large number of smart contracts with similar labels. The training data set is used to train the graph neural network. During the training process, the graph neural network vectorizes the bytecode feature graph to obtain the feature vector of the bytecode. Step 5: Take the problematic contract as the reference smart contract, and use the methods of step 1 to step 3 to obtain the bytecode feature graphs of the reference smart contract and the smart contract to be tested, respectively, and 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 bytecode similarity of smart contracts based on graph neural network according to claim 1 is characterized in that: In the 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, wherein the first recursive stack only includes 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 recursive stack and record it as the current block, and pop the symbolic execution stack, and execute the instructions in the current block sequentially on the symbolic execution stack; (2.2.3) Determine what specific operation is performed when the current block executes 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; fetch data from the top of the symbolic execution stack, i.e., the target address, and the basic block pointed to by the target address is the top block of the symbolic stack; determine 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, 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, and add a directed edge from the current block to the top block of the symbolic stack in the control flow graph, and then execute step (2.2.4); otherwise, execute step (2.2.4) directly; Case 2: The last instruction of the current block is the JUMPI instruction; at this time, the cases where the judgment condition is met and the cases where the judgment condition is not met are executed at the same time; For the case where 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, 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 yes, directly execute step (2.2.4); For situations where the judgment conditions are met, the execution operation is the same as in situation 1; Case 3: The last instruction of the current block is other than JUMP and JUMPI. In this case, directly execute step (2.2.4); (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 bytecode similarity of smart contracts based on graph neural network according to claim 1 is characterized in that: In the step 3, the basic blocks in the control flow graph are traversed, and for each basic block, the operations of recursion and generating a bytecode feature graph are performed simultaneously; The recursion is implemented through the following sub-steps: (3.1.1) Initializing a second recursive stack, wherein the second recursive stack 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 the basic block in the control flow graph, and obtain the key instructions of each predecessor block; if a predecessor block b does not have a key instruction, execute step (3.1.4); if the predecessor block b has a key instruction, add the last key instruction of the 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 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 yes, directly return to step (3.1.2); Generating the bytecode feature graph 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 and 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, 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, which 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 in the data flow graph pointing to each definition data to the bytecode feature graph.

4. The method for detecting similarity of smart contract bytecodes based on graph neural network according to claim 3 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, THROW, and STOP.

5. The method for detecting similarity of smart contract bytecodes based on graph neural network according to claim 1 is characterized in that: In the 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.

6. The method for detecting bytecode similarity of smart contracts 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 the 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, jump to the entry of the fallback function.

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

Images