A Smart Contract User Permission Abnormality Vulnerability Detection Method Based on Graph Neural Networks

Abstract

The application discloses a smart contract user permission anomaly vulnerability detection method based on a graph neural network, and comprises the following steps: S1, collecting data for model training to obtain a contract source code data set; S2, contract abstract syntax tree extraction and pre-training; S3, contract graph construction based on the abstract syntax tree; S4, permission anomaly identification based on the contract graph; and S5, obtaining a prediction result. The application detects contract permission anomaly problems based on function call information of a smart contract and access assignment information of contract storage variables, does not depend on specific vulnerability modes, can continuously update an identification model through a repeated learning method, thereby adapting to new permission control vulnerabilities, improves the accuracy of the detection method, and does not depend on transaction records and specific library methods of the contract, and therefore can be applied to general open source smart contracts, and the scalability of the detection method is improved.

Description

Technical Field

[0001] This invention relates to the field of smart contract technology, specifically to a method for detecting abnormal user permission vulnerabilities in smart contracts based on graph neural networks. Background Technology

[0002] Smart contracts, as a core technology of Blockchain 2.0, are essentially executable code published by users on the blockchain. They expand the application scenarios of blockchain, enabling its use in fields such as supply chain, smart healthcare, legal evidence preservation, and smart education. These applications rely on user interaction with smart contracts. Given the large number of user roles involved, user access control is crucial. Taking the logistics supply chain as an example, suppliers, logistics companies, and consignees are three key roles. Suppliers should have the authority to record the details of the goods supplied, logistics companies should have the authority to record the received goods and their tracking information, and consignees should have the authority to record the received goods. If a vulnerability exists in the smart contract's access control, allowing a consignee to modify the supplier's recorded information, various problems will arise. Therefore, before publishing a smart contract, developers need to test its user access management functionality to determine if any abnormal user access situations exist.

[0003] There are currently two types of solutions for detecting abnormal user permissions in smart contracts: methods based on vulnerability patterns and methods based on specific libraries.

[0004] Vulnerability pattern-based methods, such as Mythril and Securify, define abnormal user permission phenomena as contract access control problems. They define a series of vulnerability patterns, such as the "unrestricted write" pattern, which assumes that for any stored variable in a smart contract, at least one user should be unable to read or write that variable. Based on this assumption, this pattern checks whether variables in the contract can be written to by any user; if such a variable exists, the contract is considered to have an access control problem.

[0005] Methods based on specific libraries, such as SpCon, are based on the open-source permission control library "OpenZeppelin Permission Control Library". For contracts that use this library for user permission control, the method mines the user types and permissions defined in the contract based on transaction records and uses a test-based approach to detect abnormal users.

[0006] However, both of the above methods have certain drawbacks:

[0007] 1. For vulnerability pattern-based detection methods, if the vulnerability pattern is designed to be too broad, it may lead to false positives; if the vulnerability pattern is designed to be too strict, it may lead to false negatives.

[0008] 2. For methods based on a specific library, this method only applies to smart contracts that use the "OpenZeppelin permission control library". It cannot detect general contracts that do not use functions from this library.

[0009] Therefore, we need to propose a method for detecting abnormal user permissions in smart contracts based on graph neural networks. Summary of the Invention

[0010] The purpose of this invention is to provide a method for detecting abnormal user permissions in smart contracts based on graph neural networks. Abnormal contract permissions typically manifest as users being able to freely modify contract stored variables by calling specific functions within the contract. Therefore, this invention detects abnormal contract permissions based on function call information and access assignment information of contract stored variables.

[0011] To achieve the above objectives, the present invention provides the following technical solution:

[0012] A method for detecting smart contract user permission anomalies based on graph neural networks includes the following steps:

[0013] S1. Collect data for model training to obtain the contract source code dataset;

[0014] S2. Contract Abstract Syntax Tree Extraction and Pre-training, including the following steps:

[0015] S21. First, construct the abstract syntax tree of the contract. The abstract syntax tree dataset is {AST_i,L_i,i=1,2,3,…}, where AST is the abstract syntax tree of the contract.

[0016] S22. Then optimize the abstract syntax tree. Since the abstract syntax tree contains complex information, it usually needs to be preprocessed to filter out valid information. In the scenario of smart contract permission anomaly detection, the interaction relationship between smart contract functions, decorators, and global variables is mainly considered.

[0017] S23. Finally, the optimized abstract syntax tree obtained in S22 is pre-trained.

[0018] S3. Contract graph construction based on abstract syntax tree, including the following steps:

[0019] S31. Constructing graph nodes, wherein the graph nodes are of three types: function nodes, decorator nodes, and global variable nodes;

[0020] S32. Construction of edges, wherein the construction of edges includes constructing two types of edges, namely control flow information edges and data flow information edges;

[0021] S4. Permission anomaly identification based on contract graph, including the following steps:

[0022] S41. Train the abstract syntax tree contract graph obtained in S3 to obtain a trained classifier.

[0023] S42. Vulnerability identification: Set up new contract source code, convert the new contract source code into the corresponding abstract syntax tree contract graph according to the process of S2 and S3, and then input the obtained abstract syntax tree contract graph into the classifier obtained in S41 to obtain the classification result.

[0024] S5. Obtain the prediction results.

[0025] In one possible design, the contract source code dataset obtained in S1 includes smart contracts marked as having permission control issues and the source code of the smart contracts. The contract source code dataset is denoted as {SC_i,L_i,i=1,2,3,…}, where SC refers to a smart contract, L refers to the label corresponding to the contract, if i is 1, the contract is considered to have abnormal user permission issues, and if i is 0, the contract is considered to have normal user permissions.

[0026] In one possible design, the permission exception is usually caused by multiple function calls, so it is necessary to record the function definition and call information of the contract. The permission exception is reflected in the user's free modification of the contract's stored variables, so it is necessary to record the variable definition, call and assignment information of the contract.

[0027] In one possible design, the modifier is regarded as a special function in the smart contract. In S22, the abstract syntax tree is optimized. First, only the nodes in the abstract syntax tree related to the above three types of objects are retained, namely the subtree corresponding to the function, the subtree corresponding to the modifier, and the subtree corresponding to the global variable declaration, and all other nodes are deleted. Second, for the remaining nodes, only the node type information (such as function call nodes) and the node name (such as function name) are retained, and other information is deleted.

[0028] In one possible design, the abstract syntax tree is converted into a word sequence through preorder traversal. The abstract syntax tree is pre-trained using Word2Vec technology to pre-train the word sequence, which can obtain the feature vector mapping {Vec} corresponding to each word. For a word node token of an abstract syntax tree, the word vector v corresponding to the word can be calculated through Vec.

[0029] In one possible design, the function nodes are constructed using the functions of the smart contract as the granularity of graph nodes. For each function in the contract, a corresponding function node F is constructed. For each function, the corresponding function subtree can be found from the contract abstract syntax tree. The function subtree is converted into the corresponding word sequence [c1,c2,c3,…] through preorder traversal. The feature vector of the node is obtained by calculating v_F = (Vec(c1) + Vec(c2) + Vec(c3) + …) / n.

[0030] The modifier node constructs a corresponding modifier node M. For each modifier, the corresponding modifier subtree can be found from the contract abstract syntax tree. The modifier subtree is converted into the corresponding word sequence through preorder traversal. The word sequence is vector-mapped through V and the feature vector v_M of the modifier node can be obtained through calculation similar to the feature of function nodes.

[0031] The global variable node defines each global variable var defined in the contract as a graph node and calculates Vec(var) to obtain the feature vector of that node.

[0032] In one possible design, the control flow information edge is added as follows: if there is a call relationship between two functions, such as function F1 calling function F2, an edge is added from the node corresponding to F1 to the node corresponding to F2. If a function F calls decorator M, an edge is added from the node corresponding to F to the node corresponding to M.

[0033] The data flow information edges are based on the access of global variables by smart contract functions. If function F accesses the global variable Var, an edge is added from Var to F. If function F modifies the global variable Var, an edge is added from F to Var. If decorator M accesses the global variable Var, an edge is added from Var to M. If decorator M modifies the global variable Var, an edge is added from M to Var.

[0034] In one possible design, the smart contract source code is converted into, denoted as G(V, E), where V is a node of the graph, including global variable node V(var), function node V(F), and decorator node V(M), and E is an edge of the graph, including control flow information edges describing the call relationship between functions and functions (decorators), and data flow information edges describing the access and assignment relationship between functions (decorators) and global variables.

[0035] In one possible design, the abstract syntax tree contract graph is trained in S41 using a graph convolutional neural network, with the input being (the contract graph G(V,E) corresponding to the smart contract, and the label L indicating whether the contract contains permission exceptions or vulnerabilities), to obtain the trained classifier.

[0036] In one possible design, if the classification result obtained in S42 is 1, the contract is considered to have an access control issue; if the result is 0, the contract is considered not to have an access control issue.

[0037] Compared with the prior art, the beneficial effects of the present invention are:

[0038] When in use, this invention does not rely on specific vulnerability patterns. It can continuously update the identification model through repeated learning, thereby adapting to new types of access control vulnerabilities. This avoids the situation where the vulnerability pattern design is too broad, which may lead to false positives, and avoids the situation where the vulnerability pattern design is too strict, which may lead to false negatives, thus improving the accuracy of the detection method.

[0039] When used, this invention does not rely on the transaction records of the contract or specific library methods, so it can be applied to general open-source smart contracts, thus improving the scalability of the detection method. Attached Figure Description

[0040] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Please see Figure 1 The present invention provides a technical solution:

[0043] A method for detecting smart contract user permission anomalies based on graph neural networks includes the following steps:

[0044] S1. Collect data for model training to obtain the contract source code dataset;

[0045] S2. Contract Abstract Syntax Tree Extraction and Pre-training, including the following steps:

[0046] S21. First, construct the abstract syntax tree of the contract. The abstract syntax tree dataset is {AST_i,L_i,i=1,2,3,…}, where AST is the abstract syntax tree of the contract.

[0047] S22. Then optimize the abstract syntax tree. Since the abstract syntax tree contains complex information, it usually needs to be preprocessed to filter out valid information. In the scenario of smart contract permission anomaly detection, the interaction relationship between smart contract functions, decorators, and global variables is mainly considered.

[0048] S23. Finally, the optimized abstract syntax tree obtained in S22 is pre-trained.

[0049] S3. Contract graph construction based on abstract syntax tree, including the following steps:

[0050] S31. Constructing graph nodes, wherein the graph nodes are of three types: function nodes, decorator nodes, and global variable nodes;

[0051] S32. Construction of edges, wherein the construction of edges includes constructing two types of edges, namely control flow information edges and data flow information edges;

[0052] S4. Permission anomaly identification based on contract graph, including the following steps:

[0053] S41. Train the abstract syntax tree contract graph obtained in S3 to obtain a trained classifier.

[0054] S42. Vulnerability identification: Set up new contract source code, convert the new contract source code into the corresponding abstract syntax tree contract graph according to the process of S2 and S3, and then input the obtained abstract syntax tree contract graph into the classifier obtained in S41 to obtain the classification result.

[0055] S5. Obtain the prediction results.

[0056] More preferably, the contract source code dataset obtained in S1 includes smart contracts marked as having permission control issues and the source code of the smart contracts. The contract source code dataset is denoted as {SC_i,L_i,i=1,2,3,…}, where SC refers to a smart contract, L refers to the label corresponding to the contract, if i is 1, the contract is considered to have abnormal user permission issues, and if i is 0, the contract is considered to have normal user permissions.

[0057] More preferably, the permission exception is usually caused by the call of multiple functions, so it is necessary to record the function definition and call information of the contract. The permission exception is reflected in the user's free modification of the contract's stored variables, so it is necessary to record the variable definition, call and assignment information of the contract.

[0058] In a further preferred embodiment, the modifier is regarded as a special function in the smart contract. In step S22, the abstract syntax tree is optimized. First, only the nodes in the abstract syntax tree related to the above three types of objects are retained, namely the subtrees corresponding to functions, the subtrees corresponding to modifiers, and the subtrees corresponding to global variable declarations, and all other nodes are deleted. Second, for the remaining nodes, only the node type information (such as function call nodes) and the node name (such as function name) are retained, and other information is deleted.

[0059] More preferably, the abstract syntax tree is converted into a word sequence through preorder traversal. The abstract syntax tree is pre-trained using Word2Vec technology to pre-train the word sequence, which can obtain the feature vector mapping {Vec} corresponding to each word. For a word node token of an abstract syntax tree, the word vector v corresponding to the word can be calculated through Vec.

[0060] More preferably, the function nodes are constructed using the functions of the smart contract as the granularity of graph nodes. For each function in the contract, a corresponding function node F is constructed. For each function, the corresponding function subtree can be found from the contract abstract syntax tree. The function subtree is converted into the corresponding word sequence [c1,c2,c3,…] through preorder traversal. The feature vector of the node is obtained by calculating v_F = (Vec(c1) + Vec(c2) + Vec(c3) + …) / n.

[0061] The modifier node constructs a corresponding modifier node M. For each modifier, the corresponding modifier subtree can be found from the contract abstract syntax tree. The modifier subtree is converted into the corresponding word sequence through preorder traversal. The word sequence is vector-mapped through V and the feature vector v_M of the modifier node can be obtained through calculation similar to the feature of function nodes.

[0062] The global variable node defines each global variable var defined in the contract as a graph node and calculates Vec(var) to obtain the feature vector of that node.

[0063] More preferably, the control flow information edge is added as follows: if there is a call relationship between two functions, such as function F1 calling function F2, an edge is added from the node corresponding to F1 to the node corresponding to F2. If a function F calls decorator M, an edge is added from the node corresponding to F to the node corresponding to M.

[0064] The data flow information edges are based on the access of global variables by smart contract functions. If function F accesses the global variable Var, an edge is added from Var to F. If function F modifies the global variable Var, an edge is added from F to Var. If decorator M accesses the global variable Var, an edge is added from Var to M. If decorator M modifies the global variable Var, an edge is added from M to Var.

[0065] More preferably, the smart contract source code is converted into G(V, E), where V is a node of the graph, including global variable node V(var), function node V(F), and decorator node V(M). The feature vector of each node is calculated by the above steps. E is an edge of the graph, including control flow information edges describing the calling relationship between functions and functions (decorators), and data flow information edges describing the access and assignment relationship between functions (decorators) and global variables.

[0066] More preferably, in step S41, the abstract syntax tree contract graph is trained using a graph convolutional neural network, with the input being (the contract graph G(V,E) corresponding to the smart contract, and the label L indicating whether the contract contains permission exceptions or vulnerabilities), used to obtain the trained classifier.

[0067] More preferably, if the classification result obtained in S42 is 1, then the contract is considered to have an abnormal permission problem; if the result is 0, then the contract is considered not to have an abnormal permission problem.

[0068] In practical use, this invention does not rely on specific vulnerability patterns. It can continuously update the identification model through repeated learning, thereby adapting to new types of access control vulnerabilities. This avoids the situation where overly broad vulnerability pattern design may lead to false positives, and the situation where overly strict vulnerability pattern design may lead to false negatives. This improves the accuracy of the detection method. Since it does not rely on contract transaction records or specific library methods, it can be applied to general open-source smart contracts, thus improving the scalability of the detection method.

[0069] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for detecting abnormal vulnerabilities of user permissions of a smart contract based on a graph neural network, characterized in that: The method comprises the following steps: S1, collecting data for model training to obtain a contract source code data set; S2, contract abstract syntax tree extraction and pre-training, comprising the following steps: S21, first, constructing a contract abstract syntax tree, constructing an abstract syntax tree data set as {AST_i, L_i, i = 1, 2, 3, …}, wherein AST is the abstract syntax tree of the contract; S22, then, optimizing the abstract syntax tree, which needs to be preprocessed to filter effective information, and in the scenario of smart contract permission anomaly detection, the interaction relationship among functions, modifiers and global variables of the smart contract is considered; S23, finally, pre-training the optimized abstract syntax tree obtained in S22; S3, contract graph construction based on the abstract syntax tree, comprising the following steps: S31, graph node construction, the graph nodes are three types of nodes: function nodes, modifier nodes and global variable nodes; S32, edge construction, the edge construction includes construction of two types of edges, namely control flow information edges and data flow information edges; S4, permission anomaly identification based on the contract graph, comprising the following steps: S41, training the abstract syntax tree contract graph obtained in S3 to obtain a trained classifier; S42, vulnerability identification, setting a new contract source code, converting the new contract source code into a corresponding abstract syntax tree contract graph according to the processes of S2 and S3, then inputting the obtained abstract syntax tree contract graph into the classifier obtained in S41 to obtain a classification result; S5, obtaining a prediction result; The function node constructs a graph node with the function of the smart contract as the granularity, for each function in the contract, a corresponding function node F is constructed, for each function, a corresponding function subtree is found from the contract abstract syntax tree, the function subtree is converted into a corresponding word sequence [c1, c2, c3, …] through pre-order traversal, and a feature vector of the node is obtained through calculation v_F = (Vec(c1) + Vec(c2) + Vec(c3) + …) / n; The modifier node constructs a corresponding modifier node M, for each modifier, a corresponding modifier subtree is found from the contract abstract syntax tree, the modifier subtree is converted into a corresponding word sequence through pre-order traversal, the word sequence is mapped into a vector through V, and a feature vector v_M of the modifier node is obtained through a calculation similar to that of the function node feature; The global variable node defines each global variable var in the contract as a graph node, and calculates Vec(var) to obtain a feature vector of the node; The control flow information edge is an edge from the node corresponding to function F1 to the node corresponding to function F2 if there is a calling relationship between the two functions, and an edge from the node corresponding to function F to the node corresponding to modifier M if a function F calls a modifier M. The data flow information edge is based on the access of the global variable by the smart contract function, if the function F accesses the global variable Var, an edge from Var to F is added, if the function F modifies the global variable Var, an edge from F to Var is added, if the modifier M accesses the global variable Var, an edge from Var to M is added, if the modifier M modifies the global variable Var, an edge from M to Var is added; The smart contract source code is converted into G(V, E), wherein V is the node of the graph, including the global variable node V(var), the function node V(F), and the modifier node V(M), and E is the edge of the graph, including the control flow information edge describing the calling relationship between functions and the data flow information edge describing the access assignment relationship between functions and global variables.

2. The method of claim 1, wherein the method is based on a graph neural network. The contract source code dataset obtained in S1 includes the smart contract with or without permission control problem and the source code of the smart contract, and the contract source code dataset is denoted as {SC_i, L_i, i = 1, 2, 3, …}, wherein SC represents a smart contract, L represents the label corresponding to the contract, if i is 1, it is considered that the contract has a user permission abnormal problem, and if i is 0, it is considered that the contract user permission is normal.

3. The method of claim 2, wherein the method is based on a graph neural network. The permission abnormality is caused by the calling of multiple functions, so the function definition and calling information of the contract need to be recorded, and the permission abnormality is reflected in the free modification of the contract storage variable by the user, so the variable definition, calling and assignment information of the contract need to be recorded.

4. The method of claim 1, wherein the method is based on a graph neural network. The modifier is regarded as a special function in the smart contract, and the abstract syntax tree is optimized in S22. First, only the nodes related to the above three types of objects in the abstract syntax tree are retained, that is, the subtree corresponding to the function in the abstract syntax tree, the subtree corresponding to the modifier in the abstract syntax tree, and the subtree corresponding to the global variable declaration in the abstract syntax tree, and the nodes other than this are deleted. Secondly, for the remaining nodes, only the node type information and node name information are retained, and other information is deleted.

5. The method of claim 4, wherein the method is based on a graph neural network. The abstract syntax tree is converted into a word sequence by pre-order traversal, and the abstract syntax tree pre-training adopts Word2Vec technology to pre-train the word sequence to obtain a feature vector mapping {Vec} corresponding to each word. For a word node token of an abstract syntax tree, the word vector v corresponding to the word is calculated through Vec.

6. The method of claim 5, wherein the method further comprises: The abstract syntax tree contract graph is trained in S41 using a graph convolutional neural network, and the input is (the contract graph G(V, E) corresponding to the smart contract, and the label L indicating whether the contract contains a permission abnormality vulnerability), which is used to obtain a trained classifier.

7. The method of claim 1, wherein the method further comprises: determining, by the smart contract user permission anomaly vulnerability detection system, a user permission anomaly vulnerability of the smart contract based on the graph neural network. If the classification result obtained in S42 is 1, it is considered that the contract has a permission abnormality problem, and if the result is 0, it is considered that the contract does not have a permission abnormality problem.

Images