Vulnerability detection method for smart contract of power system

Abstract

The invention belongs to the technical field of power systems, particularly relates to a vulnerability detection method for a smart contract of a power system, and aims to solve the problem that vulnerability detection cannot be performed on specific business logic of the power system in the prior art. In order to solve the problems of low vulnerability detection accuracy and false alarm rate in the prior art, the invention provides the following scheme which comprises the steps of EIR design (special intermediate representation of a power system), pollution source positioning and taint analysis. The invention provides a vulnerability detection method for an intelligent contract of a power system, and aims to solve the problems of abnormal behaviors and illegal activities, such as subsidy cheating and hacker attack, caused by power transaction business development in an energy block chain. According to the method, through a transaction mode mining and machine learning method, accurate identification of potential abnormal accounts and behaviors in the energy block chain is realized, so that the ecological security of the block chain is maintained.

Description

Technical Field

[0001] The present invention relates to the technical field of power systems, and in particular, to a method for detecting vulnerabilities in smart contracts for power systems. Background Art

[0002] Smart contract: A program running on a blockchain that executes the predefined logic of its internal code. Smart contracts and users are identified by addresses on the blockchain. When a user initiates a transaction to a smart contract, it can trigger the execution of internal code snippets of the contract.

[0003] Intermediate Representation (IR): An abstract form in program analysis used to transform source code into a structure more suitable for analysis and optimization. IR is usually between source code and machine code, featuring simplicity and uniformity, enabling analysis tools to more easily perform operations such as symbolic execution and data flow analysis. It can eliminate the differences in language features and specific platforms, providing a unified perspective to help detect potential vulnerabilities, performance issues, or non-compliant behaviors. IR is a key link in static analysis, contributing to improving the analysis efficiency and accuracy.

[0004] Static analysis refers to identifying potential problems or vulnerabilities by analyzing the code itself without executing the program. In the security audit of smart contracts, static analysis discovers possible security vulnerabilities and programming errors by examining the source code of the contract. Static analysis can detect potential security vulnerabilities before the contract is deployed. Due to the immutability of the blockchain, once the contract is deployed, any vulnerability repair becomes difficult and costly. Therefore, static analysis helps to fix problems before deployment and avoid actual losses. Compared with manual auditing, static analysis can automatically scan a large amount of code and quickly discover common vulnerabilities. Especially for large and complex contracts, static analysis can more comprehensively cover potential vulnerabilities. The audit of smart contracts requires a large number of code checks. Static analysis tools can automatically detect common vulnerability patterns to assist security experts in efficiently conducting manual audits and vulnerability repairs. Although static analysis plays an important role in smart contract security, in practical applications, it still faces many challenges. Smart contracts often contain complex conditional judgments, loop structures, and external calls. Static analysis needs to accurately understand these complex control flows and identify potential security hazards. The data flow in smart contracts is relatively complex, involving changes in contract states, variable assignments, and their interactions with external data sources (such as oracles). Static analysis must be able to trace and understand the data flow, especially when the contract depends on external data, how to ensure the correctness and credibility of the external data.

[0005] Slither[1] is a static analysis tool for smart contracts, mainly used to identify potential vulnerabilities in smart contracts and ensure the security of contracts before deployment. It is the solution closest to the present invention. Slither analyzes by parsing the source code of smart contracts and using the following key technologies.

[0006] Abstract Syntax Tree (AST): AST is a data structure in a compiler that describes the syntactic structure of program code. In Slither, the AST is used to analyze the source code of the contract, helping the tool understand the syntax and logical structure of the contract. By analyzing the AST, Slither can identify potential problems in the code, such as structural problems like function calls and variable declarations.

[0007] Control Flow Graph (CFG): The control flow graph is used to represent the control flow relationships between various code blocks in a program. Slither uses the CFG to analyze the code execution paths in smart contracts, detect loops, conditional judgments, and interactions of external calls in the contract, and identify possible logical vulnerabilities and security issues. For example, Slither can identify possible re - entry attack paths in the contract through the CFG and find places where locking is required.

[0008] Slither has built - in some general vulnerability detection rules (such as re - entry attacks, integer overflows, timestamp dependencies, etc.), but these rules are mainly for general smart contract vulnerabilities and are not optimized for the unique requirements of the power grid business. Smart contracts for the power grid business may involve specific logical constraints (such as load - balancing rules, pricing rules), and these requirements need dedicated static analysis rule support, while the default rules of Slither cannot identify vulnerabilities in these specific scenarios. The power grid contract may introduce specific concepts such as nodes, and these node types are not supported in the analysis framework of Slither, resulting in insufficient vulnerability detection capabilities for specific scenarios. For example, time windows in power grid contracts (such as electricity trading settlement time, real - time price updates, etc.) are key logics, but Slither cannot identify time - dependency errors (such as unvalidated expired time windows, missing timeout logic).

[0009] The present invention mainly solves the auditing problem of smart contract code for the power grid business before deployment on the blockchain.

[0010] Smart contracts in the power system have many special smart contract vulnerabilities brought by business logics, and there is currently no code auditing method for the special business of the power system. General code auditing methods cannot be directly applied to smart contracts for power system business.

[0011] Specifically, it mainly aims at the following three types of vulnerabilities: 1. Oracle class: An oracle is an interface for smart contracts to obtain external data, such as weather, stock prices, etc. In the power grid system, the data dependence on oracles may lead to inconsistencies between on-chain and off-chain for specific power grid services, such as outage insurance compensation, issuance of green energy licenses, etc. Essentially, it is a problem of data dependence and consistency verification.

[0012] 2. Unprotected input class: Some function inputs of smart contracts are specified by transactions initiated by users. If these function inputs can manipulate some key business variables, they may be exploited by attackers, such as fraudulently obtaining subsidies by brushing transactions, falsely reporting power loads, etc. Essentially, users have obtained the ability to manipulate some key variables.

[0013] 3. Transaction order dependence class: Attackers utilize traditional transaction order dependence vulnerabilities to profit in transactions (such as auctions, front-running, etc.). Attackers exploit the transaction order dependence vulnerabilities of smart contracts in the power grid system to affect system stability (for example, different allocation orders in the power dispatching process may lead to transaction rollbacks). Essentially, it is necessary to set non-disclosed actual transaction data (power quantity, price, etc.) in specific services so that attackers cannot conduct front-running by observing transaction content.

[0014] The prior art cannot perform vulnerability detection for the specific business logic of the power system. The accuracy rate of vulnerability detection is low and the false positive rate is high.

[0015] The present invention designs a new vulnerability detection method for the specific business logic of the power system, which can detect three types of specific business logic vulnerabilities. Summary of the Invention

[0016] The present invention provides a vulnerability detection method for smart contracts in the power system, which solves the problems of the prior art that cannot perform vulnerability detection for the specific business logic of the power system, with low accuracy rate and high false positive rate of vulnerability detection.

[0017] The present invention provides the following technical solutions: A vulnerability detection method for smart contracts in the power system, the steps are as follows: S1: In the EIR design stage, first use the static analysis tool Slither to analyze the smart contract to generate the intermediate representation of the code (SlitherIR). On this basis, according to the business requirements of the power system, modify SlitherIR to generate EIR (power system-specific intermediate representation), and EIR includes node types and attributes unique to the power system, including oracle nodes, fund nodes, and condition nodes; S2: In the stain source location stage, a set of rules are designed and combined with the node types in the EIR to mark the code locations where vulnerabilities may exist, especially the stain sources of oracle nodes, fund nodes, and condition nodes. These nodes are analyzed through the rules to help discover potential security hazards. S3: In the stain analysis stage, the control flow and data flow information provided by the EIR are used to analyze the identified stain sources, and rules from the power system field are applied to check for security vulnerabilities.

[0018] The present invention aims at the matching rules for special vulnerabilities of power system smart contracts and the intermediate representation method EIR of power system smart contract code.

[0019] In the power system application scenario, since the EIR has more prior knowledge about power system auditing than SlitherIR, the accuracy rate of vulnerability detection in the present invention is greatly improved and the false positive rate is greatly reduced.

[0020] The purpose of the present invention is to provide a method for detecting smart contract vulnerabilities. Through technologies such as static analysis and stain analysis, the unique IR node types in the power system (such as oracle nodes, fund nodes, and condition nodes) are modeled, and rules are designed to identify potential vulnerabilities in smart contracts, thereby ensuring the security and stability of power system smart contracts. It should be understood that the above general description and the following detailed description are only exemplary and do not limit the present invention. Brief Description of the Drawings

[0021] Figure 1 It is a schematic diagram of the vulnerability detection work flow for a power system smart contract according to the present invention; Figure 2 It is a schematic diagram of the "control flow construction algorithm" in an embodiment of the present invention; Figure 3 It is a schematic diagram of the "data flow construction algorithm" in an embodiment of the present invention; Figure 4 It is a schematic diagram of the code design of the EIR in an embodiment of the present invention. Detailed Embodiment

[0022] The embodiments of the present invention will be described below with reference to the drawings in the embodiments of the present invention.

[0023] In the description of the embodiments of the present invention, it should be noted that unless otherwise clearly specified and limited, the terms "connection" and "installation" should be understood in a broad sense. For example, "connection" can be a detachable connection or a non-detachable connection; it can be a direct connection or an indirect connection through an intermediate medium. In addition, "communication" can be a direct communication or an indirect communication through an intermediate medium. Among them, "fixing" means that they are connected to each other and the relative positional relationship after connection remains unchanged. The orientation terms mentioned in the embodiments of the present invention, such as "inside", "outside", "top", "bottom", etc., are only references to the direction of the attached drawings. Therefore, the orientation terms used are for better and clearer explanation and understanding of the embodiments of the present invention, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus cannot be understood as a limitation to the embodiments of the present invention.

[0024] In the embodiments of the present invention, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features.

[0025] In the embodiments of the present invention, "and / or" is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this article generally represents an "or" relationship between the associated objects before and after.

[0026] The reference to "one embodiment" or "some embodiments" etc. described in this specification means that in one or more embodiments of the present invention, specific features, structures or characteristics described in combination with this embodiment are included. Thus, the statements "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments" etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "include", "comprise", "have" and their variants all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0027] The present invention provides a method for detecting vulnerabilities in smart contracts for power systems, aiming to solve problems such as abnormal behaviors and illegal activities brought about by the development of power trading services in the energy blockchain, such as subsidy fraud, hacker attacks, etc. This method realizes the accurate identification of potential abnormal accounts and behaviors in the energy blockchain through transaction pattern mining and machine learning methods to maintain the security of the blockchain ecosystem. Embodiment

[0028] This patent invents a vulnerability detection method for smart contracts in the power system. This method uses static analysis tools, combines with specific knowledge of the power system, and improves the existing intermediate representation (IR) of smart contracts to achieve more accurate vulnerability detection.

[0029] Through technologies such as static analysis and taint analysis, model the unique IR node types in the power system (such as oracle nodes, fund nodes, and condition nodes), design rules to identify potential vulnerabilities in smart contracts, and thus ensure the security and stability of smart contracts in the power system.

[0030] The specific workflow of this invention is divided into three main stages: Design EIR (special intermediate representation for the power system), taint source location, and taint analysis.

[0031] The steps are as follows: S1: In the EIR design stage, first use the static analysis tool Slither to analyze the smart contract and generate the intermediate representation of the code (SlitherIR). On this basis, according to the business requirements of the power system, modify SlitherIR to generate EIR (special intermediate representation for the power system). EIR contains the unique node types and attributes of the power system, including oracle nodes, fund nodes, and condition nodes; S2: In the taint source location stage, by designing a set of rules and combining with the node types in EIR, mark the code positions where vulnerabilities may exist, especially the taint sources of oracle nodes, fund nodes, and condition nodes, and analyze these nodes through the rules to help discover potential security risks; S3: In the taint analysis stage, use the control flow and data flow information provided by EIR to analyze the identified taint sources, apply the rules from the power system field, and check for security vulnerabilities.

[0032] The specific technical details are as follows: 1. EIR design: EIR is an improvement of SlitherIR, inherits most of the node types of SlitherIR, and makes special modifications to some nodes to better meet the requirements of the power system. EIR includes two core parts: node types and node attributes. The specific code design is as Figure 4 shown; Node types: Three important node types are defined in EIR: oracle nodes, fund nodes, and condition nodes. Each node type corresponds to a specific taint source, and different taint analysis rules need to be designed according to the node type.

[0033] Node attributes: The node attributes in the EIR are used to record control flow and data flow information, providing a more comprehensive view of data interaction, thereby helping to analyze potential vulnerabilities in smart contracts. These attributes help in deeply understanding how data flows in the contract and how different parts interact.

[0034] The algorithm for constructing the control flow is as Figure 2 shown. It requires two inputs: a node and a search direction (parent node is "before", child node is "after"). The algorithm initializes an empty list "checks" to store nodes with conditional expressions and initializes two sets to track visited nodes and nodes to be traversed. In each iteration, the algorithm pops a node from the list of nodes to be processed. If this node has been visited, it skips further processing. Otherwise, it marks the node as visited and, if the node contains a conditional expression, it adds this node to the "checks" list. Then, the algorithm determines which nodes to visit next based on the specified direction. If the direction is "before", it appends all predecessor nodes to the list of nodes to be processed. If the direction is "after", it appends all successor nodes. This process continues until all reachable nodes in the specified direction have been visited. Finally, the algorithm returns the list of nodes with conditional checks, representing the control flow information of the input node.

[0035] The algorithm for constructing the control flow is as Figure 3 shown. This algorithm identifies the data flow path between two variables in the dependency graph. It takes a dependency dictionary and two variables as inputs. The algorithm uses a depth - first search method to explore the path from the first variable "var1" to the target variable "var2". Initially, it marks the starting variable as visited and adds it to the current path. If the current variable matches the target, the algorithm returns the path. Otherwise, it recursively explores each adjacent variable that has not been visited. During this recursive process, if a valid path to the target is found, it immediately returns. If there is no path through a particular branch, the algorithm backtracks, removing the current variable from the path and the set of visited nodes. Finally, if all possibilities are exhausted without finding a path, it returns None. This method effectively reveals the data flow dependencies between the specified variables.

[0036] 2. Determine the pollution source The purpose of pollution source location is to mark the nodes in the contract that may have vulnerabilities through rules. Different rules are designed for each node type in the EIR.

[0037] 2.1 oracle nodes Oracle nodes are used to obtain external data. If the external data is not properly verified, it may introduce vulnerabilities. We designed two rules to identify the pollution sources of oracle nodes: Rule 1: In an assignment statement, if the value of a variable comes from an external data source (such as oracle), it is marked as a tainted source.

[0038] Rule 2: In an assignment statement involving an oracle call, if the value on the right side is an oracle call, then this node is a tainted source.

[0039] 2.2 fund node The fund node is used to handle the fund flow in the smart contract. The rules we designed focus on identifying those nodes that can send funds to ensure the security of fund operations.

[0040] Rule: If a node in the EIR can send funds (such as ir.node.can_send_eth() == True), then this node is a tainted source.

[0041] 2.3 condition node The condition node is used to perform logical judgments in the smart contract. If there are logical errors, it may lead to rollbacks. We designed rules to identify tainted sources in logical judgments.

[0042] Rule: If a node contains a conditional expression, it is marked as a tainted source.

[0043] 3. Taint analysis The taint analysis stage is used to detect whether there are security vulnerabilities in the tainted sources. By deeply analyzing the control flow and data flow of the tainted sources, potential vulnerabilities are discovered. The specific vulnerabilities and taint analysis detection rules are as follows.

[0044] Oracle - type vulnerabilities: The timeliness of oracle nodes is a crucial requirement in the power system. The present invention designs pre - condition checks and post - time checks to ensure the correctness and timeliness of oracle data and prevent system problems caused by inconsistent oracle data.

[0045] (Detection rule: Determine whether the pollution source has been verified in terms of time consistency and multi - variable propagation consistency) Unprotected input - type vulnerabilities: In the power system, users may control key variables to manipulate rewards. To prevent unauthorized users from controlling key variables, the present invention checks the pre - conditions of the fund node to ensure that only authorized users can operate these variables.

[0046] (Detection rule: Determine whether the manipulation permission of the pollution source propagates to the user).

[0047] Transaction order - dependent vulnerability: The transaction order in the power system may affect the stability of the system. The present invention monitors the propagation path of sensitive variables in the condition node to prevent attackers from manipulating the transaction order to affect the system stability.

[0048] (Detection rule: Determine whether the transparency of contaminated data may cause a transaction rollback, that is, whether the variables propagated by the pollution source trigger the conditional judgment statement for transaction rollback before being encrypted).

[0049] The above are only the specific implementation manners of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should all be covered within the protection scope of the present invention; without conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A vulnerability detection method for power system smart contracts, characterized in that: Here are the steps: S1: In the EIR design phase, the static analysis tool Slither is first used to analyze the smart contract and generate the intermediate representation of the code (SlitherIR). On this basis, SlitherIR is modified to generate EIR (power system specific intermediate representation) according to the business needs of the power system. EIR contains node types and attributes unique to the power system, including oracle nodes, fund nodes, and condition nodes; S2: In the taint source location phase, a set of rules are designed to mark the code locations where vulnerabilities may exist, especially the taint sources of oracle nodes, fund nodes, and condition nodes, by combining the node types in the EIR. These nodes are analyzed through rules to help discover potential security risks. S3: The taint analysis phase uses the control flow and data flow information provided by the EIR to analyze the identified taint sources, applying rules from the power system field to check whether there are security vulnerabilities.

Images