Smart contract detection method and apparatus, and storage medium

Abstract

The application provides a smart contract detection method and device and a storage medium, relates to the technical field of blockchains, and can accurately detect a smart contract with a low false alarm rate. The method comprises the following steps: obtaining source code of a smart contract to be detected; constructing a feature map corresponding to the source code based on the semantics of the source code, and determining a feature matrix and edge features corresponding to the feature map; inputting the feature matrix and the edge features into a target detection model for vulnerability detection processing to obtain a vulnerability detection result; and using the vulnerability detection result to represent the probability of the existence of a vulnerability in the smart contract to be detected.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a smart contract detection method, device and storage medium. Background Technology

[0002] Smart contracts are automated contracts based on blockchain technology. If vulnerabilities exist in a smart contract, they can lead to security issues (such as the leakage of sensitive information). Therefore, before deploying a smart contract on a blockchain network, a security audit is often required to identify code errors and vulnerabilities and mitigate risks in advance.

[0003] General techniques primarily employ signature-based code matching for automated auditing of smart contracts. However, this method has low accuracy and a high false positive rate. Summary of the Invention

[0004] This application provides a smart contract detection method, apparatus, and storage medium, which can accurately detect smart contracts with a low false alarm rate.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] In a first aspect, this application provides a smart contract detection method, which includes: obtaining the source code of the smart contract to be detected; constructing a feature map corresponding to the source code based on the semantics of the source code, and determining the feature matrix and edge features corresponding to the feature map; inputting the feature matrix and edge features into a target detection model for vulnerability detection processing to obtain vulnerability detection results; the vulnerability detection results are used to represent the probability that there are vulnerabilities in the smart contract to be detected.

[0007] One possible approach involves constructing a feature map corresponding to the source code based on its semantics. This includes: performing semantic analysis on the source code to determine multiple functions and variables, as well as multiple primary and secondary relationships. The primary relationships represent the association between functions and variables, including data flow or control flow relationships. The secondary relationships represent the association between different functions, including call or callback relationships. The multiple functions and variables are configured as multiple nodes, and based on the primary and secondary relationships, the connection edges between different nodes are determined to obtain the feature map.

[0008] In one possible approach, based on multiple first relations and multiple second relations, the connection edges between different nodes in the multiple nodes are determined, including: when the first relations include data flow relations, the connection edges between the first node and the second node in the multiple nodes are determined as directed edges from the first node to the second node; the first node is used to represent the node obtained by function configuration corresponding to the data flow relations; the second node is used to represent the node obtained by variable configuration corresponding to the data flow relations; when the first relations include control flow relations, the connection edges between the first node and the second node in the multiple nodes are determined as directed edges from the third node to the fourth node; the third node is used to represent the node obtained by function configuration corresponding to the control flow relations; Section 4 A node is used to represent a node obtained by configuring variables corresponding to a control flow relationship. When the second relationship includes a call relationship, the connection edge between the fifth and sixth nodes among multiple nodes is determined as a directed edge from the fifth node to the sixth node. The fifth node is used to represent a node obtained by configuring the function that initiates the call in the call relationship. The sixth node is used to represent a node obtained by configuring the function in the call relationship. When the second relationship includes a callback relationship, the connection edge between the seventh and eighth nodes among multiple nodes is determined as a directed edge from the seventh node to the eighth node. The seventh node is used to represent a node obtained by configuring the function before the callback in the callback relationship. The eighth node is used to represent a node obtained by configuring the function after the callback in the callback relationship.

[0009] One possible approach further includes: performing a first operation on multiple connecting edges with the same direction between two nodes in the feature graph to obtain a first feature graph; the first operation includes: merging the feature vectors on the multiple connecting edges to obtain a merged feature vector; deleting multiple connecting edges and reconstructing the connecting edges between the two nodes, and determining the merged feature vector as the feature vector of the connecting edge; performing a second operation on each node in the first feature graph to obtain a second feature graph; the second operation includes: adding the negative of the sum of the out-degree feature vectors of the node to the feature vector of the node, and adding the in-degree feature vector of the node to the feature vector of the node; the out-degree feature vector is used to represent the feature vector corresponding to the directed edge from the node to other nodes; the in-degree feature vector is used to represent the feature vector corresponding to the directed edge pointing to the node; determining a first feature matrix and a first edge feature corresponding to the second feature graph, and inputting the first feature matrix and the first edge feature into the target detection model for vulnerability detection processing to obtain a first vulnerability detection result.

[0010] One possible approach further includes: acquiring multiple negative sample data and multiple positive sample data; using negative sample data to represent smart contract source code containing vulnerabilities; using positive sample data to represent smart contract source code not containing vulnerabilities; constructing multiple third feature maps that correspond one-to-one with the multiple negative sample data based on the semantics of the multiple negative sample data, and determining the relationships between the multiple third features...Figure 1 Multiple second feature matrices and multiple second edge features are corresponding to each other; based on the semantics of multiple positive sample data, multiple fourth feature maps that correspond one-to-one with the multiple positive sample data are constructed, and the relationships between the multiple fourth features are determined. Figure 1 A corresponding set of multiple third feature matrices and multiple third edge features are used; based on the multiple second feature matrices, multiple second edge features, third feature matrices, and third edge features, the initial detection model is trained to obtain the target detection model.

[0011] One possible approach includes generating a vulnerability detection report based on the vulnerability detection results; the vulnerability detection report includes: vulnerability type, vulnerability location, vulnerability triggering conditions, potential impact, vulnerability severity, and vulnerability remediation recommendations.

[0012] Secondly, this application provides a smart contract detection device, which includes: an acquisition unit, a determination unit, and a detection unit; the acquisition unit is used to acquire the source code of the smart contract to be detected; the determination unit is used to construct a feature map corresponding to the source code based on the semantics of the source code acquired by the acquisition unit, and determine the feature matrix and edge features corresponding to the feature map; the detection unit is used to input the feature matrix and edge features determined by the determination unit into a target detection model for vulnerability detection processing, and obtain a vulnerability detection result; the vulnerability detection result is used to represent the probability that a vulnerability exists in the smart contract to be detected.

[0013] In one possible approach, the unit is determined specifically by: performing semantic analysis on the source code to identify multiple functions and multiple variables, as well as multiple first relations and multiple second relations; the first relations are used to represent the association between functions and variables, including data flow relations or control flow relations; the second relations are used to represent the association between different functions, including call relations or callback relations; the multiple functions and multiple variables are configured as multiple nodes, and based on the multiple first relations and multiple second relations, the connection edges between different nodes in the multiple nodes are determined to obtain a feature graph.

[0014] In one possible approach, the determining unit is specifically used for: when the first relationship includes a data flow relationship, determining the connection edge between the first node and the second node among multiple nodes as a directed edge from the first node to the second node; the first node is used to represent a node obtained by function configuration corresponding to the data flow relationship; the second node is used to represent a node obtained by variable configuration corresponding to the data flow relationship; when the first relationship includes a control flow relationship, determining the connection edge between the first node and the second node among multiple nodes as a directed edge from the third node to the fourth node; the third node is used to represent a node obtained by function configuration corresponding to the control flow relationship; the fourth node is used to represent a node obtained by function configuration corresponding to the control flow relationship. The nodes are configured by variables; when the second relationship includes a call relationship, the connection edge between the fifth and sixth nodes among multiple nodes is determined as a directed edge from the fifth node to the sixth node; the fifth node is used to represent the node configured by the function that initiates the call in the call relationship; the sixth node is used to represent the node configured by the function in the call relationship; when the second relationship includes a callback relationship, the connection edge between the seventh and eighth nodes among multiple nodes is determined as a directed edge from the seventh node to the eighth node; the seventh node is used to represent the node configured by the function before the callback in the callback relationship; the eighth node is used to represent the node configured by the function after the callback in the callback relationship.

[0015] In one possible embodiment, the apparatus further includes: a processing unit; the processing unit is configured to perform a first operation on multiple connecting edges with the same direction between two nodes in the feature graph to obtain a first feature graph; the first operation includes: merging the feature vectors on the multiple connecting edges to obtain a merged feature vector; deleting the multiple connecting edges and reconstructing the connecting edges between the two nodes, and determining the merged feature vector as the feature vector of the connecting edge; the processing unit is further configured to perform a second operation on each node in the first feature graph to obtain a second feature graph; the second operation includes: adding the negative of the sum of the out-degree feature vectors of the node to the feature vector of the node, and adding the in-degree feature vector of the node to the feature vector of the node; the out-degree feature vector is used to represent the feature vector corresponding to the directed edge from the node to other nodes; the in-degree feature vector is used to represent the feature vector corresponding to the directed edge pointing to the node; and a determining unit is further configured to determine a first feature matrix and a first edge feature corresponding to the second feature graph, and input the first feature matrix and the first edge feature into a target detection model for vulnerability detection processing to obtain a first vulnerability detection result.

[0016] One possible approach further includes: an acquisition unit, also configured to acquire multiple negative sample data and multiple positive sample data; the negative sample data representing smart contract source code containing vulnerabilities; and the positive sample data representing smart contract source code not containing vulnerabilities; and a determination unit, further configured to construct multiple third feature maps corresponding one-to-one with the multiple negative sample data based on the semantics of the multiple negative sample data, and determine the corresponding third feature maps. Figure 1 The unit is used to determine multiple second feature matrices and multiple second edge features corresponding to each other, and is also used to construct multiple fourth feature maps that correspond one-to-one with the semantics of multiple positive sample data, and to determine the multiple fourth feature maps. Figure 1 The detection unit is also used to train the initial detection model based on the multiple second feature matrices, multiple second edge features, third feature matrices, and third edge features to obtain the target detection model.

[0017] One possible approach also includes: a generation unit; the generation unit is used to generate a vulnerability detection report based on the vulnerability detection results; the vulnerability detection report includes: vulnerability type, vulnerability location, vulnerability triggering conditions, potential impact, vulnerability severity, and vulnerability remediation recommendations.

[0018] Thirdly, this application provides a smart contract detection device, which includes: a processor and a communication interface; the communication interface and the processor are coupled, and the processor is used to run computer programs or instructions to implement the smart contract detection method as described in the first aspect and any possible implementation of the first aspect.

[0019] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed on a terminal, cause the terminal to perform the smart contract detection method as described in the first aspect and any possible implementation thereof.

[0020] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a smart contract detection device, cause the smart contract detection device to execute the smart contract detection method as described in the first aspect and any possible implementation thereof.

[0021] In a sixth aspect, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface and the processor being coupled, the processor being used to run computer programs or instructions to implement the smart contract detection method as described in the first aspect and any possible implementation thereof.

[0022] Specifically, the chip provided in this application embodiment also includes a memory for storing computer programs or instructions.

[0023] In this application, the name of the aforementioned smart contract detection device does not limit the device or functional module itself. In actual implementation, these devices or functional modules may appear under other names. As long as the functions of each device or functional module are similar to those in this application, they fall within the scope of the claims of this application and their equivalents.

[0024] These or other aspects of this application will become more readily apparent in the following description.

[0025] Based on any of the above aspects, the technical solution provided in this application brings at least the following beneficial effects:

[0026] After obtaining the source code of the smart contract to be detected, a feature map corresponding to the source code can be constructed based on the semantics of the source code, and the feature matrix and edge features corresponding to the feature map can be determined. The feature matrix and edge features are then input into the target detection model for vulnerability detection processing to obtain the vulnerability detection results.

[0027] Compared to general techniques that primarily employ feature code matching for automated smart contract detection, the method provided in this application utilizes a target detection model to perform vulnerability detection on the feature matrix and edge features corresponding to the source code, avoiding the low accuracy and high false positive rate issues of general techniques. Therefore, this application can accurately detect smart contracts with a low false positive rate. Attached Figure Description

[0028] Figure 1 A schematic diagram illustrating the deployment of a smart contract in a multi-layered Internet of Things (IoT) system, provided as an embodiment of this application;

[0029] Figure 2 This is a schematic diagram of the structure of a smart contract detection system provided in an embodiment of this application;

[0030] Figure 3 A schematic diagram illustrating the deployment of a smart contract as provided in an embodiment of this application;

[0031] Figure 4 This is a schematic diagram of the hardware structure of a smart contract detection device provided in an embodiment of this application;

[0032] Figure 5 A flowchart illustrating a smart contract detection method provided in an embodiment of this application;

[0033] Figure 6 A schematic diagram illustrating how to obtain the source code of a smart contract, as provided in an embodiment of this application;

[0034] Figure 7A schematic diagram comparing the architectures of an object detection model and a graph convolutional model provided in an embodiment of this application;

[0035] Figure 8 A flowchart illustrating another smart contract detection method provided in this application embodiment;

[0036] Figure 9 A flowchart illustrating another smart contract detection method provided in this application embodiment;

[0037] Figure 10 A flowchart illustrating another smart contract detection method provided in this application embodiment;

[0038] Figure 11 A flowchart illustrating another smart contract detection method provided in this application embodiment;

[0039] Figure 12 A schematic diagram of a smart contract detection process provided in an embodiment of this application;

[0040] Figure 13 This is a schematic diagram of another smart contract detection device provided in an embodiment of this application. Detailed Implementation

[0041] The smart contract detection method and apparatus provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0042] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0043] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0044] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0045] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0046] With the rapid development of IoT and edge computing technologies, the intelligence level of terminal devices is constantly improving, generating more multi-dimensional data metrics. This data is crucial for optimizing system performance, enhancing user experience, and supporting intelligent decision-making. However, due to data fragmentation, privacy concerns, and security issues related to data exchange between devices, a data platform is needed to centrally store and process this data for further data mining.

[0047] As a platform for centralized data management and processing, a data middle platform can collect, store, and analyze data from various terminal devices, providing powerful support for data mining. Data mining through a data middle platform can help us gain a deeper understanding of the operational status of terminal devices, user consumption behavior, and market demand, thereby providing enterprises with more accurate decision-making basis and business insights. However, with the continuous increase in the number of IoT devices, the security issues of data sharing and exchange are becoming increasingly prominent. Since edge devices typically have limited computing and storage capabilities and cannot perform complex encryption and authentication operations, we need to find a solution to ensure data security and scalability.

[0048] Blockchain technology is a decentralized, distributed, and trusted database maintained by a peer-to-peer network through a designated consensus mechanism. Typically, blockchain technology is used in the field of digital assets and cryptocurrencies. However, considering the drawbacks of centralized servers in data management and storage, researchers are currently turning to decentralized methods for storing and managing data collected from IoT devices.

[0049] Smart contracts are a type of contract that executes automatically and cannot be terminated manually, solving the problem of mutual distrust between transacting parties. In blockchain smart contracts, IoT information is not stored in blocks, but rather in code containing all relevant contract information. Once the contract is completed and meets all the requirements of the IoT participating nodes, it is deployed to the blockchain network and begins execution.

[0050] By leveraging the combined application of technologies such as blockchain, smart contracts, and edge computing, the data security and scalability issues faced by edge IoT devices can be effectively addressed. Blockchain technology provides a decentralized approach to data storage and exchange, ensuring data integrity and security. Its decentralized nature allows data to be backed up across multiple nodes, thereby improving data reliability and durability. When smart contracts are combined with blockchain technology, the security and reliability of data storage and management can be further enhanced. Smart contracts are automatically executed contracts that cannot be manually terminated. Through pre-written program code, they ensure the permissions and security of data access.

[0051] Meanwhile, edge computing technology distributes data processing and analysis tasks to edge nodes closest to the data source, thereby reducing data transmission and processing latency. This approach offers enhanced security and privacy protection because data is processed locally rather than transmitted to remote servers. The combined application of these technologies will provide a more secure, reliable, and effective solution for data storage and management of IoT devices.

[0052] The multi-layered architecture of the Internet of Things (IoT) provides a suitable framework for deploying blockchain systems. For example, such as... Figure 1 As shown, Figure 1 This diagram illustrates the deployment of smart contracts in a multi-layered Internet of Things (IoT) system. Due to resource constraints on edge devices (such as base stations or gateways), smart contracts can be deployed at the edge layer to provide smart contract services to IoT devices. For example, when an IoT device sends a request, the edge device can perform autonomous operations based on the smart contract under predetermined conditions. This management model pushes more computing and storage resources to IoT devices and brings several benefits, including reduced response times for time-sensitive IoT applications and the elimination of centralized authority. However, vulnerabilities in smart contracts can lead to significant financial losses or the leakage of sensitive information.

[0053] In a blockchain architecture, the edge layer processes and verifies transactions, ensuring data security and privacy. This layer can include nodes in a distributed network that exchange data and information through peer-to-peer connections.

[0054] The cloud service layer can provide scalable and reliable storage and computing resources to support the operation of blockchain networks. By storing data in the cloud, centralized management and access control of data can be achieved. At the same time, cloud service providers can offer a variety of tools and services to help developers build, deploy, and manage blockchain applications.

[0055] The IoT device layer can include various physical devices, such as sensors and actuators. These devices can connect and exchange information via the internet to enable the automatic execution of smart contracts and real-time data sharing. By introducing blockchain technology into the device layer, the credibility and security of data can be enhanced, while also promoting interoperability and collaborative work between devices.

[0056] Researchers have conducted in-depth studies on the security issues caused by smart contract vulnerabilities. Currently, the best approach to smart contract vulnerability detection is to perform security audits before deploying the smart contract to the blockchain network. This allows for the early detection of potential code errors and vulnerabilities, mitigating potential risks in advance. In the field of smart contract security, code auditing is generally divided into two methods: manual review and automated review. Since manual auditing is time-consuming and labor-intensive, it is inefficient and cannot meet the growing demand for smart contract auditing. Therefore, currently, most smart contract audits are performed using automation. Automated auditing can be categorized into three types based on auditing characteristics: feature-based code matching automated auditing, formal verification-based automated auditing, and symbolic execution and symbolic abstraction-based automated auditing. Each of these three types of automated auditing methods has the following drawbacks:

[0057] 1. Automated Auditing of Feature-Based Code Matching: Feature-based code matching auditing involves extracting features from malicious code, abstracting these features into semantic matching algorithms, and then matching them against the static source code of the contract. This method is similar to static code analysis. The advantages of this method are its very fast matching speed and rapid response to new vulnerabilities. Feature-based code matching auditing methods are typically developed as plugins. When a new vulnerability emerges, developers simply submit the new matching pattern as a plugin to the auditing system.

[0058] However, this method also has some drawbacks. Since most blockchain smart contracts are not open source, we can only obtain their opcodes. Analyzing opcodes is very difficult for security analysts; some security personnel spend considerable effort reverse engineering opcodes, which limits the applicability of signature-based auditing methods. Furthermore, compared to traditional static code auditing methods, signature-based auditing methods have a higher false negative rate.

[0059] 2. Automated Auditing Technology Based on Formal Verification: This method mainly utilizes the Isabelle Higher Order Logic Interaction Theorem Prover to transform the EVM's Opcode into a formal model. The verification of this formal model is then used to determine if vulnerabilities exist in the smart contract code. Initially, researchers used Lem Language as the conversion method, but due to its low efficiency, they later adopted F-framework and K-framework to transform the DVM into a formal model.

[0060] However, despite the advantages of formal verification-based auditing methods, their level of automation remains low, requiring secondary verification by technical personnel.

[0061] 3. Automated auditing methods based on symbolic execution and symbolic abstraction are among the most widely used approaches. This method involves analyzing smart contracts, compiling the source code into Ethereum Virtual Machine (EVM) opcodes, and inputting this opcode into an automated analysis engine. The automated analysis engine converts the common characteristics of the smart contract code into a control flow diagram, and then uses symbolic execution and symbolic abstraction methods to analyze it and determine whether the smart contract code contains vulnerabilities.

[0062] Automated verification systems based on symbolic execution and symbolic abstraction mainly include Mythril, Oyente, Maian, and Securify. These systems can effectively reduce the false positive and false negative rates in smart contract vulnerability detection. However, the drawbacks of this approach are that the analysis methods are relatively complex and cumbersome, requiring a long analysis time. Furthermore, this method cannot verify the correctness of smart contract functionality.

[0063] Existing automated code vulnerability detection methods suffer from the following problems. First, the false positive rate is high, meaning many false vulnerability reports exist. Therefore, automated auditing cannot completely replace secondary review by technical personnel and still requires human intervention. Second, the degree of automation is relatively low, requiring continuous feedback and improvement to enhance audit effectiveness. This means the system needs frequent updates and adjustments to adapt to new vulnerability types and changing smart contract code. Finally, the detection time is long. For example, Mythril, Oyente, and Securify are some well-known automated detection systems, with each detection taking approximately 60 seconds, 30 seconds, and 20 seconds, respectively. This can lead to significant time consumption during large-scale smart contract audits.

[0064] To address the shortcomings of general technologies, the smart contract detection method provided in this application, after obtaining the source code of the smart contract to be detected, can construct a feature map corresponding to the source code based on the semantics of the source code, and determine the feature matrix and edge features corresponding to the feature map. The feature matrix and edge features are then input into the target detection model for vulnerability detection processing to obtain the vulnerability detection result.

[0065] Compared to general techniques that primarily employ feature code matching for automated smart contract detection, the method provided in this application utilizes a target detection model to perform vulnerability detection on the feature matrix and edge features corresponding to the source code, avoiding the low accuracy and high false positive rate issues of general techniques. Therefore, this application can accurately detect smart contracts with a low false positive rate.

[0066] For example, such as Figure 2 The diagram shown is a structural schematic of a smart contract detection system 100 provided in an embodiment of this application. The smart contract detection system 100 may include a smart contract detection device 101 and a data acquisition device 102. A communication connection can be established between the smart contract detection device 101 and the data acquisition device 102.

[0067] In practical applications, the smart contract detection device 101 can communicate with one or more data acquisition devices 102.

[0068] For ease of understanding, this application uses the communication connection between a smart contract detection device 101 and a data acquisition device 102 as an example for illustration.

[0069] Optional, Figure 2 The smart contract detection device 101 and data acquisition device 102 can be functional modules integrated into the same device, or they can be two independently set devices. This application does not impose any restrictions on this.

[0070] It is easy to understand that when the smart contract detection device 101 and the data acquisition device 102 are functional modules integrated within the same device, the communication method between the smart contract detection device 101 and the data acquisition device 102 is the same as the communication method between internal modules of the device. In this case, the communication process between the two is the same as that between the smart contract detection device 101 and the data acquisition device 102 when they are set up independently.

[0071] For ease of understanding, this application mainly uses the example of the smart contract detection device 101 and the data acquisition device 102 being set up independently of each other.

[0072] Figure 2The smart contract detection device 101 can receive the source code of the smart contract sent by the data acquisition device 102, and construct the feature map corresponding to the source code based on the semantics of the source code, and determine the feature matrix and edge features corresponding to the feature map, so as to further input the feature matrix and edge features into the target detection model for vulnerability detection processing and obtain vulnerability detection results.

[0073] Optionally, Figure 2 The smart contract detection device 101 and data acquisition device 102 can be terminals, servers, or other types of electronic devices. Figure 2 The diagram shown is merely an example of the device configuration of the smart contract detection device 101 and the data acquisition device 102, and does not constitute a limitation thereof.

[0074] When the smart contract detection device 101 and data acquisition device 102 are terminals, the terminal can be a device providing voice and / or data connectivity to a user, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. The terminal can communicate with one or more core networks via a radio access network (RAN). The terminal can be a mobile terminal, such as a computer with a mobile terminal, or a portable, pocket-sized, handheld, or computer-embedded mobile device that exchanges voice and / or data with the radio access network, such as a mobile phone, tablet, laptop, netbook, or personal digital assistant (PDA). This application does not impose any limitations on this.

[0075] When the smart contract detection device 101 and the data acquisition device 102 are servers, the server can be a single server or a server cluster consisting of multiple servers. In some embodiments, the server cluster can also be a distributed cluster. This application does not impose any limitations on this.

[0076] Optionally, combined Figure 2 ,like Figure 3 As shown, smart contracts can be deployed on blockchain nodes. When the smart contract detection device 101 and the data acquisition device 102 are functional modules integrated into the same device, the module can obtain the source code of the smart contract from the blockchain node.

[0077] like Figure 4 The diagram shown is a hardware structure schematic of a smart contract detection device provided in an embodiment of this application. The smart contract detection device includes a processor 21, a memory 22, a communication interface 23, and a bus 24. The processor 21, memory 22, and communication interface 23 are connected via the bus 24.

[0078] Processor 21 is the control center of the smart contract detection device. It can be a single processor or a collective term for multiple processing elements. For example, processor 21 can be a general-purpose central processing unit (CPU) or other general-purpose processors. Among them, the general-purpose processor can be a microprocessor or any conventional processor.

[0079] As one embodiment, processor 21 may include one or more CPUs, for example Figure 4 CPU 0 and CPU 1 are shown in the diagram.

[0080] The memory 22 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0081] In one possible implementation, the memory 22 can exist independently of the processor 21. The memory 22 can be connected to the processor 21 via a bus 24 and is used to store instructions or program code. When the processor 21 calls and executes the instructions or program code stored in the memory 22, it can implement the smart contract detection method provided in the following embodiments of this application.

[0082] In another possible implementation, the memory 22 can also be integrated with the processor 21.

[0083] Communication interface 23 is used for the smart contract detection device to connect with other devices via a communication network, which can be Ethernet, wireless access network, wireless local area network (WLAN), etc. Communication interface 23 may include a receiving unit for receiving data and a sending unit for sending data.

[0084] Bus 24 can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0085] It should be pointed out that, Figure 4 The structure shown does not constitute a limitation on smart contract detection devices, except Figure 4 In addition to the components shown, the smart contract detection device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0086] like Figure 5 The diagram shown is a flowchart illustrating a smart contract detection method provided in an embodiment of this application. This smart contract detection method can be applied to... Figure 2 The smart contract detection device 101 of the smart contract detection system 100 shown. The smart contract detection method includes: S301-S303.

[0087] S301, The smart contract detection device obtains the source code of the smart contract to be detected.

[0088] Source code refers to an uncompiled text file written according to a specific programming language specification; it is a series of human-readable computer language instructions. The source code of a smart contract is an uncompiled text file written according to a specific programming language specification; it is a series of human-readable computer language instructions. For example, source code can be written in programming languages ​​such as Java, C, C++, C#, Pascal, or Python.

[0089] Source code may include at least one code segment, each representing an independent block of code that can perform a specific function or accomplish a specific task.

[0090] Optionally, the smart contract detection device can obtain the source code of a smart contract from an electronic device storing the smart contract via communication or physical connection, or it can obtain the source code of a smart contract from an IoT blockchain. This application does not impose specific limitations in this regard.

[0091] For example, such as Figure 6The diagram illustrates one method for obtaining the source code of a smart contract. A smart contract detection device can obtain the source code of a smart contract from an IoT blockchain. The source code obtained by the smart contract detection device is as follows:

[0092]

[0093] S302 The smart contract detection device constructs a feature map corresponding to the source code based on the semantics of the source code, and determines the feature matrix and edge features corresponding to the feature map.

[0094] In one possible approach, the smart contract detection device can perform semantic analysis on the source code to identify multiple functions and variables, as well as multiple primary and secondary relationships. The device can then configure these functions and variables as multiple nodes and, based on the primary and secondary relationships, determine the connection edges between different nodes to obtain a feature graph. The specific implementation of the smart contract detection device constructing the feature graph corresponding to the source code based on its semantics can be found in S401-S402 below, and will not be elaborated further here.

[0095] In one possible approach, the smart contract detection device can determine the number of nodes and the node dimensions of the feature graph. The device can then construct a feature matrix consisting of the number of nodes multiplied by the node dimensions. The elements of this feature matrix can represent the characteristics of the corresponding node in a specific dimension.

[0096] For example, the smart contract detection device determines that the feature graph has n nodes and f node dimensions. The smart contract detection device can construct a feature matrix X of size n×f. ij This can be used to represent the value of the j-th feature of the i-th node. The f-dimensional feature vector of the i-th node satisfies the following first formula:

[0097] X i ∈R f , i = 1, 2, ..., n.

[0098] Among them, X i R can be used to represent the f-dimensional feature vector of the i-th node. i can represent the i-th node. f can represent the f-th dimension. R can represent the value of the feature vector.

[0099] Edge features

[0100] In one possible approach, the smart contract detection device can construct a tensor based on the feature map and identify the tensor as edge features.

[0101] For example, the smart contract detection device can determine an n×n×p tensor A based on the number of nodes n in the feature graph, and define tensor A as the edge feature of the feature graph. The p-dimensional tensor feature connecting the i-th node and the j-th node can be represented by A. ijp express.

[0102] Here, i can be used to represent the i-th node. j can be used to represent the j-th node. p can be used to represent the connection of the p-dimensional tensor features.

[0103] S303 The smart contract detection device inputs the feature matrix and edge features into the target detection model for vulnerability detection processing to obtain vulnerability detection results.

[0104] The vulnerability detection result is used to indicate the probability that a vulnerability exists in the smart contract to be detected.

[0105] In one possible approach, the vulnerability detection device can input feature matrices and edge features into a target detection model for vulnerability detection processing. The target detection model may include multiple edge feature-enhanced graph convolutional network (EFE-GCN) layers. The target detection can perform vulnerability detection processing on the feature matrices and edge features using multiple feature matrices and edge features to obtain the vulnerability detection results.

[0106] For example, such as Figure 7 The diagram shows a comparison of the architectures of an object detection model and a graph convolutional model. The vulnerability detection device can input the feature matrix X and edge features A into the object detection model for detection processing. The object detection device uses multiple EFE-GCN layers to perform vulnerability detection processing on the feature matrix X and edge features A, obtaining the vulnerability detection results.

[0107] The calculation formula for the EFE-GCN layer satisfies the following second formula: Second formula:

[0108]

[0109] Among them, X n It can be used to represent the feature matrix of the output of the nth EFE-GCN layer. X n-1 This can be used to represent the feature matrix output of the (n-1)th EFE-GCN layer. A n-1 It can be used to represent the edge features of the output of the nth EFE-GCN layer. It can be used to represent A n-1 The adjacency matrix of W. 0 It can be used to represent the weight matrix obtained from model training. LeakyReLu can be used to represent activation functions.

[0110] For example, when n is 1, the following third formula is satisfied. Third formula:

[0111]

[0112] Here, X1 can be used to represent the feature matrix of the first EFE-GCN layer output. X0 can be used to represent the feature matrix of the initial output. A0 can be used to represent the edge features of the initial output. This can be used to represent the adjacency matrix of A0. W (0) It can be used to represent the weight matrix obtained from model training.

[0113] For example, when n is 2, the following fourth formula is satisfied. Fourth Formula:

[0114]

[0115] Here, X2 can be used to represent the feature matrix of the output of the second EFE-GCN layer. X1 can be used to represent the feature matrix of the initial output. A1 can be used to represent the edge features of the initial output. This can be used to represent the adjacency matrix of A1. W (0) It can be used to represent the weight matrix obtained from model training.

[0116] For example, when n is 3, the following fifth formula is satisfied. Fifth Formula:

[0117]

[0118] Here, X3 can be used to represent the feature matrix output of the third EFE-GCN layer. X2 can be used to represent the feature matrix output of the second EFE-GCN layer. A2 can be used to represent the edge features output of the second EFE-GCN layer. This can be used to represent the adjacency matrix of A2. W (0) It can be used to represent the weight matrix obtained from model training.

[0119] In one possible approach, the graph convolutional model includes multiple GCN layers. During detection processing, the feature matrix can be modified through the GCN layers, while the edge features remain unchanged.

[0120] Based on the above technical solution, the smart contract detection method provided in this application can, after obtaining the source code of the smart contract to be detected, construct a feature map corresponding to the source code based on the semantics of the source code, and determine the feature matrix and edge features corresponding to the feature map, so as to further input the feature matrix and edge features into the target detection model for vulnerability detection processing and obtain vulnerability detection results.

[0121] Compared to general techniques that primarily employ feature code matching for automated smart contract detection, the method provided in this application utilizes a target detection model to perform vulnerability detection on the feature matrix and edge features corresponding to the source code, avoiding the low accuracy and high false positive rate issues of general techniques. Therefore, this application can accurately detect smart contracts with a low false positive rate.

[0122] In one embodiment, combined with Figure 5 When a smart contract detection device constructs a feature map corresponding to the source code based on the semantics of the source code, such as... Figure 8 As shown in the embodiments of this application, the smart contract detection method further includes: S401-S402.

[0123] S401, The smart contract detection device performs semantic analysis on the source code to determine the multiple functions and variables included in the source code, as well as multiple first relations and multiple second relations.

[0124] The first relationship can be used to represent the association between functions and variables, including data flow relationships or control flow relationships. The second relationship can be used to represent the association between different functions, including call relationships or callback relationships.

[0125] In one possible approach, the smart contract detection device can perform semantic decomposition on the source code and semantic analysis on the decomposed source code to identify multiple functions and variables, as well as multiple first relations and multiple second relations included in the source code.

[0126] For example, the following code is a piece of source code edited in C language.

[0127]

[0128]

[0129] The smart contract detection device can perform semantic analysis on this source code to identify the `perform_operation` function, the `print_result` function, and the `main` function. It can also identify the variables `x`, `y`, and `result` in this source code.

[0130] The smart contract detection device can determine the first relationship based on the semantics of this source code: the data flow relationship between the main function and variables x and y, and the control flow relationship between the main function and variable result. The second relationship can also be determined based on the semantics of this source code: the call relationship between the main function and the perform_operation function, and the callback relationship between the print_result function and the perform_operation function.

[0131] For example, Table 1 below is a semantic conversion mapping table. The smart contract detection device can perform semantic conversion on the source code based on Table 1.

[0132] Table 1

[0133]

[0134] S402, The smart contract detection device configures multiple functions and multiple variables as multiple nodes, and determines the connection edges between different nodes in the multiple nodes based on multiple first relations and multiple second relations, thereby obtaining a feature graph.

[0135] In one possible approach, to enable effective vulnerability detection of smart contract source code, a smart contract detection device can be configured with multiple functions and multiple variables as multiple nodes.

[0136] Optionally, the smart contract detection device can identify primary and secondary nodes from multiple functions and variables. For example, when detecting reentrancy vulnerabilities, the smart contract detection device can identify the transfer function and built-in event function in the call relationship as primary nodes. Alternatively, when detecting vulnerabilities dependent on timestamps, the smart contract detection device can identify the timestamp function as the primary node. Or, when detecting infinite loop vulnerabilities, the smart contract detection device can identify all functions in the source code as primary nodes. The smart contract detection device can mark primary nodes. For example, primary nodes can be represented by M1, M2, etc. Furthermore, when the primary node is a function in a call relationship, variables can be identified as secondary nodes. The smart contract detection device can mark secondary nodes. For example, primary nodes can be represented by S1, S2, etc.

[0137] One possible approach is to identify primary and secondary nodes to better examine the source code, thereby uncovering potential problems and vulnerabilities. Furthermore, this method can better illustrate the code execution process. Therefore, identifying primary and secondary nodes can improve the accuracy of smart contract detection.

[0138] Optionally, the smart contract testing device can also identify callback functions as callback nodes. These callback nodes can simulate and test various possible scenarios within the smart contract to uncover potential security vulnerabilities. This allows for a more detailed analysis and understanding of the smart contract's execution process, improving security. Therefore, by defining callback nodes, a more comprehensive testing and evaluation of smart contracts can be achieved.

[0139] In one possible approach, the smart contract detection device can determine the connection edges between different nodes among multiple nodes based on multiple first relations and multiple second relations, thereby obtaining a feature graph. Here, the connection edges represent the relationships between functions, or between functions and variables.

[0140] Based on this, the smart contract detection method provided in this application can perform semantic analysis on the source code, thereby configuring multiple functions and variables in the source code as multiple nodes, and determining the connection edges between different nodes based on multiple first relations and multiple second relations, thus obtaining a feature map. This enables the smart contract detection device to detect smart contracts using a target detection model. Therefore, this application can accurately detect smart contracts.

[0141] In one embodiment, combined with Figure 8 When a smart contract detection device determines the connection edges between different nodes among multiple nodes based on multiple first relationships and multiple second relationships, such as... Figure 9 As shown in the embodiments of this application, the smart contract detection method further includes: S501-S504.

[0142] S501, the smart contract detection device, when the first relationship includes a data flow relationship, determines the connection edge between the first node and the second node among multiple nodes as a directed edge from the first node to the second node.

[0143] The first node can be used to represent a node obtained by configuring the function corresponding to the data flow relationship. The second node can be used to represent a node obtained by configuring the variable corresponding to the data flow relationship.

[0144] For example, by considering the data flow relationship between the main function and variable x in the source code of the example in S401, the smart contract detection device can configure the main function as the first node and the variable x as the second node. The smart contract detection device can then determine the directed edge from the first node to the second node.

[0145] S502. When the first relationship includes a control flow relationship, the smart contract detection device determines the connection edge between the third node and the fourth node among multiple nodes as a directed edge from the third node to the fourth node.

[0146] The third node can be used to represent a node obtained by configuring the function corresponding to the control flow relationship. The fourth node can be used to represent a node obtained by configuring the variable corresponding to the control flow relationship.

[0147] For example, by considering the control flow relationship between the main function and the variable result in the source code of the example in S401, the smart contract detection device can identify the main function as the third node and the variable result as the fourth node. The smart contract detection device can then identify the directed edge from the third node to the fourth node.

[0148] S503, when the second relationship includes a calling relationship, the smart contract detection device determines the connection edge between the fifth node and the sixth node among multiple nodes as a directed edge from the fifth node to the sixth node.

[0149] The fifth node can be used to represent a node configured by the function that initiates the call in the call relationship. The sixth node can be used to represent a node configured by the function in the call relationship.

[0150] For example, by considering the call relationship between the main function and the perform_operation function in the source code of the example in S401, the smart contract detection device can identify the main function that initiates the call as the fifth node and the perform_operation function that is called as the sixth node. The smart contract detection device can then identify the directed edge from the fifth node to the sixth node.

[0151] S504. When the second relationship includes a callback relationship, the smart contract detection device determines the connection edge between the seventh node and the eighth node among multiple nodes as a directed edge from the seventh node to the eighth node.

[0152] The seventh node can be used to represent the node obtained from the function configuration before the callback in a callback relationship. The eighth node can be used to represent the node obtained from the function configuration after the callback in a callback relationship.

[0153] For example, by combining the callback relationship between the `print_result` function and the `perform_operation` function in the source code of the example in S401, the smart contract detection device can determine the `print_result` function before the callback as the seventh node and the `perform_operation` function after the callback as the eighth node. The smart contract detection device can then determine the directed edge from the seventh node to the eighth node.

[0154] It should be understood that Figure 9The flowchart of the smart contract detection method does not specify the execution order of S501, S502, S503, and S504. That is, S501, S502, S503, and S504 can be executed simultaneously or separately.

[0155] Based on this, the smart contract detection method provided in this application can determine the connection edges between different nodes based on variables and functions, as well as the relationships between functions. This supports the smart contract detection device in determining the feature map corresponding to the source code of the smart contract. Therefore, this application can accurately detect smart contracts.

[0156] In one embodiment, such as Figure 10 As shown in the embodiments of this application, the smart contract detection method further includes: S601-S603.

[0157] S601, The smart contract detection device performs a first operation on multiple connecting edges with the same direction between two nodes in the feature graph to obtain a first feature graph.

[0158] The first operation may include: merging the feature vectors on multiple connecting edges to obtain a merged feature vector; deleting multiple connecting edges and reconstructing the connecting edges between the two nodes; and using the merged feature vector as the feature vector of the connecting edge.

[0159] In one possible approach, because the functions and variables in the source code of a smart contract may have various relationships between them, the smart contract detection device constructs a complex graph based on the semantics of the source code. However, smart contract detection devices may have drawbacks in feature extraction from complex graphs, which could affect the effectiveness and performance of feature extraction. For example, drawbacks may include the computational complexity of complex graphs, which typically contain a large number of nodes and edges, increasing computational complexity and causing feature extraction to consume more computational resources and time.

[0160] Alternatively, a drawback could include the risk of overfitting. Features in a complex graph may be too specific to the complex structures in the training data, increasing the risk of overfitting. This means the model's performance may degrade on unfamiliar data.

[0161] Alternatively, a drawback could include difficulty in interpretation. Features in complex graphs are often highly abstract and complex, potentially involving multiple nodes and numerous connecting edges, making them difficult to interpret and understand intuitively.

[0162] Based on this, the smart contract detection device can merge the feature vectors of multiple connecting edges to obtain a merged feature vector. The device can also delete multiple connecting edges and reconstruct the connecting edges between two nodes, using the merged feature vector as the feature vector for the connecting edge.

[0163] S602, The smart contract detection device performs a second operation on each node in the first feature map to obtain a second feature map.

[0164] The second operation may include: adding the negative of the node's out-degree feature vector to the node's feature vector, and adding the node's in-degree feature vector to the node's feature vector. The out-degree feature vector represents the feature vector corresponding to the directed edges from the node to other nodes. The in-degree feature vector represents the feature vector corresponding to the directed edges pointing to the node.

[0165] Understandably, out-degree can be used to represent the number of edges originating from one node and pointing to other nodes. In-degree can be used to represent the number of edges originating from other nodes and pointing to one node. Out-degree feature vector can be used to represent the feature vector corresponding to the edges originating from one node and pointing to other nodes. In-degree feature vector can be used to represent the feature vector of the edges originating from other nodes and pointing to one node.

[0166] In one possible approach, for each of the multiple nodes, the smart contract detection device can add the inverse of the node's out-degree feature vector to the node's feature vector and add the node's in-degree feature vector to the node's feature vector.

[0167] S603, the smart contract detection device determines the first feature matrix and the first edge feature corresponding to the second feature map, inputs the first feature matrix and the first edge feature into the target detection model for vulnerability detection processing, and obtains the first vulnerability detection result.

[0168] In one possible approach, the smart contract detection device determines the specific implementation of the first feature matrix and the first edge feature corresponding to the second feature map. This can be referred to in the above-described S302, where the smart contract detection device determines the implementation of the feature matrix and edge feature corresponding to the feature map, which will not be elaborated here.

[0169] In one possible approach, the smart contract detection device inputs the first feature matrix and the first edge feature into the target detection model for vulnerability detection processing to obtain the first vulnerability detection result. The specific implementation method can refer to the implementation method in S303 above, where the smart contract detection device inputs the feature matrix and edge feature into the target detection model for vulnerability detection processing to obtain the vulnerability detection result.

[0170] Based on this, the smart contract detection method provided in this application can perform a first operation and a second operation on the feature map, thereby reducing the complexity of the feature map, improving the efficiency of model training, reducing the risk of overfitting, and improving the detection accuracy.

[0171] In one embodiment, such as Figure 11 As shown in the embodiments of this application, the smart contract detection method further includes: S701-S704.

[0172] S701, the smart contract detection device acquires multiple negative sample data and multiple positive sample data.

[0173] Negative sample data can be used to represent smart contract source code that includes vulnerabilities. Positive sample data can be used to represent smart contract source code that does not include vulnerabilities.

[0174] In one possible approach, the smart contract detection device can be configured with a storage module. This storage module can be used to store multiple negative sample data and multiple positive sample data pre-configured by the staff.

[0175] Based on this, when it is necessary to train the initial detection model, the smart contract detection device can read negative sample data and positive sample data from the configured storage module.

[0176] Alternatively, the smart contract detection device can obtain the source code of a smart contract from an electronic device storing the smart contract via communication or physical connection, or it can obtain the source code of a smart contract from an IoT blockchain. This application does not impose specific limitations in this regard.

[0177] S702, the smart contract detection device constructs multiple third feature maps that correspond one-to-one with the semantics of multiple negative sample data, and determines the relationships between the multiple third feature maps and the negative sample data. Figure 1 One corresponds to multiple second feature matrices and multiple second edge features.

[0178] In one possible approach, the smart contract detection device constructs multiple third feature maps that correspond one-to-one with the semantics of multiple negative sample data, and determines the relationships between these third feature maps and the negative sample data. Figure 1 The specific implementation methods of the multiple second feature matrices and multiple second edge features corresponding to one can refer to S302 above, where the smart contract detection device constructs the feature map corresponding to the source code based on the semantics of the source code, and determines the implementation methods of the feature matrix and edge features corresponding to the feature map. It will not be elaborated here.

[0179] S703, the smart contract detection device, based on the semantics of multiple positive sample data, constructs multiple fourth feature maps that correspond one-to-one with the multiple positive sample data, and determines the relationships between the multiple fourth feature maps and the positive sample data. Figure 1One corresponds to multiple third feature matrices and multiple third edge features.

[0180] In one possible approach, the smart contract detection device constructs multiple fourth feature maps that correspond one-to-one with the semantics of multiple positive sample data, and determines the relationships between the multiple fourth feature maps and the positive sample data. Figure 1 One corresponds to multiple third feature matrices and multiple third edge features. Referring to S302 above, the smart contract detection device constructs a feature map corresponding to the source code based on the semantics of the source code, and determines the implementation method of the feature matrix and edge features corresponding to the feature map, which will not be elaborated here.

[0181] It should be understood that Figure 11 The flowchart of the smart contract detection method does not restrict the execution order of S702 and S702. That is, S702 and S702 can be executed simultaneously or separately. In other words, the smart contract detection device can construct multiple third feature maps corresponding one-to-one with the semantics of multiple negative sample data, and determine the relationships between these third feature maps and the corresponding negative sample data. Figure 1 While constructing multiple second feature matrices and multiple second edge features corresponding to each other, based on the semantics of multiple positive sample data, multiple fourth feature maps corresponding one-to-one with the multiple positive sample data are constructed, and the relationships between the multiple fourth features are determined. Figure 1 This involves multiple third feature matrices and multiple third edge features corresponding to each other. Alternatively, the smart contract detection device can first construct multiple third feature maps that correspond one-to-one with the semantics of multiple negative sample data, and determine the relationships between these multiple third features and the corresponding edge features. Figure 1 Based on the semantics of multiple positive sample data, multiple fourth feature maps corresponding one-to-one with the multiple positive sample data are constructed, and the relationships between the multiple fourth feature maps and the positive sample data are determined. Figure 1 This involves multiple third feature matrices and multiple third edge features corresponding to each other. Alternatively, the smart contract detection device can first construct multiple fourth feature maps that correspond one-to-one with the semantics of multiple positive sample data, and determine the relationships between these multiple fourth features and the corresponding edge features. Figure 1 Based on the semantics of multiple negative sample data, multiple third feature matrices and multiple third edge features are constructed, and then multiple third feature maps corresponding one-to-one with the multiple negative sample data are determined. Figure 1 One corresponds to multiple second feature matrices and multiple second edge features.

[0182] S704 The smart contract detection device trains the initial detection model based on multiple second feature matrices, multiple second edge features, multiple third feature matrices, and multiple third edge features to obtain the target detection model.

[0183] In one possible approach, the smart contract detection device can input the second feature matrix, the second edge feature, the third feature matrix, and the third edge feature into the initial detection model for detection processing, obtain the detection results of the initial detection model, and determine the loss value of the initial detection model based on the detection results of each initial detection model.

[0184] If the loss value of an initial detection model is greater than a preset loss threshold, the smart contract detection device can adjust the parameters in the initial detection model until the loss value of the initial detection model is less than or equal to the preset loss threshold, thus obtaining the target detection model corresponding to the initial detection model.

[0185] In one possible approach, during model training, the initial detection model automatically adjusts its weights using machine learning algorithms to reduce the deviation between the initial detection model's output and the actual results. For example, gradient descent can be used to reduce the loss value by calculating the gradient of the initial detection model's output with respect to the model weights.

[0186] Specifically, the smart contract detection device can input a first test set containing multiple second feature matrices and multiple second edge features into an initial detection model for detection processing to obtain a first detection result. Furthermore, the smart contract detection device can determine a first loss value between the first detection result and the negative sample detection result.

[0187] Based on this, when the first loss value is greater than the preset loss threshold, the smart contract detection device can adjust the parameters in the initial detection model and train the adjusted initial detection model based on the second test set in multiple sample feature data.

[0188] Alternatively, when the first loss value is less than or equal to a preset loss threshold, the smart contract detection device can obtain a target detection model.

[0189] Optionally, the first test set can be any number of second feature matrices and second edge features selected from multiple second feature matrices and multiple second edge features. The second test set can also be any number of second feature matrices and multiple second edge features selected from multiple second feature matrices and multiple second edge features.

[0190] Optionally, the preset loss threshold can be reasonably set by staff according to actual needs. For example, 0.1 and 0.15, etc. This application does not impose specific restrictions on this.

[0191] In one possible approach, the smart contract detection device trains the initial detection device using multiple third feature matrices and multiple third edge features. This method can be referenced from the method described above for training the initial detection device using multiple third feature matrices and multiple third edge features, and will not be repeated here.

[0192] Based on this, the smart contract detection method provided in this application can train an initial detection model using multiple negative sample data and multiple positive sample data to obtain a target detection model, thereby supporting the detection of smart contracts through the target detection model and obtaining detection results. Therefore, this application can accurately detect smart contracts.

[0193] In one embodiment, the smart contract detection method provided in this application further includes: S801.

[0194] S801, the smart contract detection device generates a vulnerability detection report based on the vulnerability detection results.

[0195] The vulnerability detection report includes: vulnerability type, vulnerability location, vulnerability triggering conditions, potential impact, vulnerability severity, and vulnerability remediation recommendations.

[0196] In one possible approach, the detection result output by the target detection model can be a probability vector about the probability of a vulnerability. For example, the target detection model outputs a detection result of [0.1, 0.7, 0.1, 0.1].

[0197] The first value, 0.1, represents a probability of 0.1 for a vulnerability-free system. The second value, 0.7, represents a probability of 0.7 for a reentrant vulnerability. The third value, 0.1, represents a probability of 0.1 for an overflow vulnerability. The fourth value, 0.1, represents a probability of 0.1 for an infinite loop vulnerability.

[0198] Based on this, the smart contract detection device can determine whether the vulnerability corresponding to the probability vector is a reentrant vulnerability and generate a vulnerability detection report.

[0199] For example, a vulnerability detection report may take the following form:

[0200] 1. Reentrancy vulnerability:

[0201] Description: A reentrancy vulnerability exists in the source code of the smart contract, which could lead to unexpected state modifications.

[0202] Location: Line 100 of the smart contract's source code.

[0203] Triggering condition: When a smart contract calls an external smart contract and then calls the same or another contract before the call is completed.

[0204] Potential impact: Attackers could repeatedly call smart contracts, leading to unauthorized state modifications.

[0205] Severity: High.

[0206] Recommended fix: Use a mutex or place the modification operation after the check.

[0207] 2. Overflow vulnerability.

[0208] Description: An overflow vulnerability exists in the smart contract, which may lead to numerical calculation errors.

[0209] Location: Line 200 of the smart contract's source code.

[0210] Trigger condition: When the input value exceeds the valid range.

[0211] Potential impact: Numerical calculation errors may lead to unexpected contractual behavior, and special care should be taken in handling the input range.

[0212] Severity: High.

[0213] Recommended fix: Implement overflow checks for numerical calculations.

[0214] Based on this, the smart contract detection method provided in this application can generate a vulnerability detection report based on the vulnerability detection results, thereby improving code security and making it easier for developers to solve problems.

[0215] In one embodiment, such as Figure 12 The diagram shown is a schematic of a smart contract detection process.

[0216] In one possible approach, the smart contract detection device can obtain the source code of smart contracts from an IoT blockchain. Based on the source code, the device can generate a feature map and simplify it into a simple graph. This simple graph can include graph labels, edge features, node relationships, and node features. The device can then input the edge features and feature matrix corresponding to the simple graph into a target detection model for processing, obtaining the detection results. The target detection model contains multiple EFE-GCN layers, a single-linear layer, and a fully linear layer. The EFE-GCN layer includes EFE-GCN, an activation function, and a batch normalization layer. The device can then identify vulnerabilities in the detection results and generate a vulnerability detection report.

[0217] For example, such as Figure 13 The diagram shown is a structural schematic of a smart contract detection device provided in an embodiment of this application. The smart contract detection device is used to execute the smart contract detection method provided in this application. For example, the above... Figure 5 , Figure 8 , Figure 9 , Figure 10 and Figure 11 The method for detecting smart contracts in the present invention. The smart contract detection device may include: an acquisition unit 901, a determination unit 902, a detection unit 903, a processing unit 904, and a generation unit 905.

[0218] In one possible approach, acquisition unit 901 is used to acquire the source code of the smart contract to be tested. For example, acquisition unit 901 is used to execute... Figure 5 Step S301 in the process.

[0219] In one possible approach, the determining unit 902 is used to construct a feature map corresponding to the source code based on the semantics of the source code acquired by the acquiring unit, and to determine the feature matrix and edge features corresponding to the feature map. For example, the determining unit 902 is used to perform... Figure 5 Step S302 in the process.

[0220] In one possible approach, the detection unit 903 is used to input the feature matrix and edge features determined by the determining unit into the target detection model for vulnerability detection processing to obtain vulnerability detection results. For example, the detection unit 903 is used to execute... Figure 5 Step S303 in the process.

[0221] In one possible approach, the determining unit 902 is specifically used to: perform semantic analysis on the source code to determine multiple functions and variables, as well as multiple first relations and multiple second relations, included in the source code. The multiple functions and variables are configured as multiple nodes, and based on the multiple first relations and multiple second relations, the connection edges between different nodes are determined to obtain a feature map. For example, the determining unit 902 is specifically used to execute... Figure 8 Steps S401-S402 in the process.

[0222] In one possible approach, the determining unit 902 is specifically configured to: when the first relationship includes a data flow relationship, determine the connection edge between the first node and the second node among multiple nodes as a directed edge from the first node to the second node. When the first relationship includes a control flow relationship, determine the connection edge between the first node and the second node among multiple nodes as a directed edge from the third node to the fourth node. When the second relationship includes a call relationship, determine the connection edge between the fifth node and the sixth node among multiple nodes as a directed edge from the fifth node to the sixth node. When the second relationship includes a callback relationship, determine the connection edge between the seventh node and the eighth node among multiple nodes as a directed edge from the seventh node to the eighth node. For example, the determining unit 902 is specifically configured to execute... Figure 9 Steps S501-S504 in the process.

[0223] In one possible approach, processing unit 904 is configured to perform a first operation on multiple connecting edges with the same direction between two nodes in the feature map to obtain a first feature map. For example, processing unit 904 is configured to perform... Figure 10 Step S601 in the process.

[0224] In one possible approach, processing unit 904 is further configured to perform a second operation on each node in the first feature map to obtain a second feature map. For example, processing unit 904 is configured to perform... Figure 10 Step S602 in the process.

[0225] In one possible approach, the determining unit 902 is further configured to determine a first feature matrix and a first edge feature corresponding to the second feature map, and input the first feature matrix and the first edge feature into the target detection model for vulnerability detection processing to obtain a first vulnerability detection result. For example, the determining unit 902 is configured to execute... Figure 10 Step S603 in the process.

[0226] In one possible approach, the acquisition unit 901 is also used to acquire multiple negative sample data and multiple positive sample data. For example, the acquisition unit 901 is used to perform... Figure 11 Step S701 in the process.

[0227] In one possible approach, the determining unit 902 is further configured to construct multiple third feature maps corresponding one-to-one with the multiple negative sample data based on the semantics of the multiple negative sample data, and determine the multiple third feature maps. Figure 1 One corresponds to multiple second feature matrices and multiple second edge features. For example, determining unit 902 is used to perform... Figure 11 Step S702 in the process.

[0228] In one possible approach, the determining unit 902 is further configured to construct multiple fourth feature maps corresponding one-to-one with the multiple positive sample data based on the semantics of the multiple positive sample data, and determine the multiple fourth feature maps. Figure 1 One corresponds to multiple third feature matrices and multiple third edge features. For example, determining unit 902 is used to perform... Figure 11 Step S703 in the process.

[0229] In one possible approach, detection unit 903 is further configured to train an initial detection model based on multiple second feature matrices, multiple second edge features, a third feature matrix, and third edge features to obtain a target detection model. For example, detection unit 903 is configured to perform... Figure 11 Step S704 in the process.

[0230] In one possible approach, generation unit 905 is used to generate a vulnerability detection report based on the vulnerability detection results. For example, generation unit 905 is used to execute step S801.

[0231] also, Figure 13 The technical effects of the smart contract detection device can be referred to the technical effects of the smart contract detection method in the above embodiments, and will not be repeated here.

[0232] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0233] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to execute the smart contract detection method described in the above method embodiments.

[0234] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the smart contract detection method in the method flow shown in the above method embodiments.

[0235] The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: electrical connections having one or more wires; portable computer disks; hard disks; random access memory (RAM); read-only memory (ROM); erasable programmable read-only memory (EPROM); registers; hard disks; optical fibers; portable compact disc read-only memory (CD-ROM); optical storage devices; magnetic storage devices; or any suitable combination thereof; or any other form of computer-readable storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium may also be a component of the processor. The processor and the storage medium may reside in an application-specific integrated circuit (ASIC). In the embodiments of this application, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0236] Since the smart contract detection device, computer-readable storage medium, and computer program product in the embodiments of this application can be applied to the above method, the technical effects they can achieve can also be referred to the above method embodiments. The embodiments of this application will not be repeated here.

[0237] The above is merely a specific implementation method of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A smart contract detection method, characterized in that, include: Obtain the source code of the smart contract to be tested; Based on the semantics of the source code, a feature map corresponding to the source code is constructed, and the feature matrix and edge features corresponding to the feature map are determined. The feature matrix is ​​constructed based on the feature vectors of the nodes of the feature map in different dimensions; the edge features are tensors constructed based on the feature map. The feature matrix and the edge features are input into the target detection model for vulnerability detection processing to obtain the vulnerability detection result. The vulnerability detection result is used to indicate the probability that a vulnerability exists in the smart contract to be detected; The method further includes: A first operation is performed on multiple connecting edges with the same direction between two nodes in the feature map to obtain a first feature map; the first operation includes: merging the feature vectors on the multiple connecting edges to obtain a merged feature vector; deleting the multiple connecting edges and reconstructing the connecting edges between the two nodes, and determining the merged feature vector as the feature vector of the connecting edge; Perform a second operation on each node in the first feature graph to obtain a second feature graph; the second operation includes: adding the negative of the sum of the out-degree feature vectors of the node to the feature vector of the node, and adding the in-degree feature vector of the node to the feature vector of the node; the out-degree feature vector is used to represent the feature vector corresponding to the directed edge from the node to other nodes; the in-degree feature vector is used to represent the feature vector corresponding to the directed edge pointing to the node; A first feature matrix and a first edge feature corresponding to the second feature map are determined, and the first feature matrix and the first edge feature are input into the target detection model for vulnerability detection processing to obtain a first vulnerability detection result.

2. The smart contract detection method according to claim 1, characterized in that, The step of constructing a feature map corresponding to the source code based on the semantics of the source code includes: Semantic analysis is performed on the source code to determine that the source code includes multiple functions and multiple variables, as well as multiple first relationships and multiple second relationships; the first relationship is used to represent the association between the function and the variable, including data flow relationship or control flow relationship; the second relationship is used to represent the association between different functions, including call relationship or callback relationship; The plurality of functions and the plurality of variables are configured as a plurality of nodes, and based on the plurality of first relations and the plurality of second relations, the connection edges between different nodes in the plurality of nodes are determined to obtain the feature graph.

3. The smart contract detection method according to claim 2, characterized in that, The step of determining the connection edges between different nodes among the plurality of nodes based on the plurality of first relationships and the plurality of second relationships includes: When the first relationship includes a data flow relationship, the connection edge between the first node and the second node among the plurality of nodes is determined as a directed edge from the first node to the second node; the first node is used to represent the node obtained by the function configuration corresponding to the data flow relationship; the second node is used to represent the node obtained by the variable configuration corresponding to the data flow relationship. When the first relationship includes a control flow relationship, the connection edge between the third node and the fourth node among the plurality of nodes is determined as a directed edge from the third node to the fourth node; the third node is used to represent the node obtained by the function configuration corresponding to the control flow relationship; the fourth node is used to represent the node obtained by the variable configuration corresponding to the control flow relationship. In the case where the second relationship includes a calling relationship, the connecting edge between the fifth node and the sixth node among the plurality of nodes is determined as a directed edge from the fifth node to the sixth node; the fifth node is used to represent the node obtained by the function that initiates the call in the calling relationship; the sixth node is used to represent the node obtained by the function in the calling relationship. In the case where the second relationship includes a callback relationship, the connection edge between the seventh node and the eighth node among the plurality of nodes is determined as a directed edge from the seventh node to the eighth node; the seventh node is used to represent the node obtained by the function configuration before the callback in the callback relationship; the eighth node is used to represent the node obtained by the function configuration after the callback in the callback relationship.

4. The smart contract detection method according to claim 1, characterized in that, Also includes: Acquire multiple negative sample data and multiple positive sample data; the negative sample data is used to represent the source code of a smart contract that contains vulnerabilities; The positive sample data is used to indicate that the source code of the smart contract that does not contain vulnerabilities is not included; Based on the semantics of multiple negative sample data, multiple third feature maps corresponding one-to-one with the multiple negative sample data are constructed, and multiple second feature matrices and multiple second edge features corresponding one-to-one with the multiple third feature maps are determined. Based on the semantics of the multiple positive sample data, multiple fourth feature maps corresponding one-to-one with the multiple positive sample data are constructed, and multiple third feature matrices and multiple third edge features corresponding one-to-one with the multiple fourth feature maps are determined. The initial detection model is trained based on the plurality of second feature matrices, the plurality of second edge features, the third feature matrix, and the third edge features to obtain the target detection model.

5. The smart contract detection method according to claim 1, characterized in that, Also includes: Generate a vulnerability detection report based on the vulnerability detection results; The vulnerability detection report includes: vulnerability type, vulnerability location, vulnerability triggering conditions, potential impact, vulnerability severity, and vulnerability remediation recommendations.

6. A smart contract detection device, characterized in that, include: Acquisition unit, construction unit, detection unit, and processing unit; The acquisition unit is used to acquire the source code of the smart contract to be detected; The construction unit is used to construct a feature map corresponding to the source code based on the semantics of the source code obtained by the acquisition unit, and to determine the feature matrix and edge features corresponding to the feature map. The feature matrix is ​​constructed based on the feature vectors of the nodes of the feature map in different dimensions; the edge features are tensors constructed based on the feature map. The detection unit is used to input the feature matrix and edge features determined by the determining unit into the target detection model for vulnerability detection processing to obtain vulnerability detection results; the vulnerability detection results are used to represent the probability that there are vulnerabilities in the smart contract to be detected. The processing unit is configured to perform a first operation on multiple connecting edges with the same direction between two nodes in the feature map to obtain a first feature map; the first operation includes: merging the feature vectors on the multiple connecting edges to obtain a merged feature vector; deleting the multiple connecting edges and reconstructing the connecting edges between the two nodes, and determining the merged feature vector as the feature vector of the connecting edge; The processing unit is further configured to perform a second operation on each node in the first feature graph to obtain a second feature graph; the second operation includes: adding the negative of the sum of the out-degree feature vectors of the node to the feature vector of the node, and adding the in-degree feature vector of the node to the feature vector of the node; the out-degree feature vector is used to represent the feature vector corresponding to the directed edge from the node to other nodes; the in-degree feature vector is used to represent the feature vector corresponding to the directed edge pointing to the node; The determining unit is further configured to determine the first feature matrix and the first edge feature corresponding to the second feature map, input the first feature matrix and the first edge feature into the target detection model for vulnerability detection processing, and obtain the first vulnerability detection result.

7. The smart contract detection device according to claim 6, characterized in that, The building unit is specifically used for: Semantic analysis is performed on the source code to determine that the source code includes multiple functions and multiple variables, as well as multiple first relations and multiple second relations; the first relations are used to represent the association between the functions and the variables, including data flow relations or control flow relations; The second relationship is used to represent the association between different functions, including calling relationships or callback relationships; The plurality of functions and the plurality of variables are configured as a plurality of nodes, and based on the plurality of first relations and the plurality of second relations, the connection edges between different nodes in the plurality of nodes are determined to obtain the feature graph.

8. A smart contract detection device, characterized in that, include: Processor and communication interface; The communication interface is coupled to a processor, which is used to run computer programs or instructions to implement the smart contract detection method as described in any one of claims 1-5.

9. A computer-readable storage medium storing instructions, characterized in that, When the computer executes the instruction, the computer performs the smart contract detection method as described in any one of claims 1-5.

Images