Lightning loan attack identification method and storage medium

Abstract

This application discloses a method and storage medium for identifying flash loan attacks. The method includes: monitoring the target blockchain through a preset Ethereum full node to obtain a first event log; constructing a first event token flow graph based on the first event log; determining whether a flash loan transaction exists in the first event log based on the first event token flow graph; when a flash loan transaction exists in the first event log, identifying the target AMM node and its corresponding target smart contract bytecode and historical transaction data; determining a first price model and a second price model corresponding to the target smart contract bytecode and historical transaction data, respectively, and determining a comprehensive price model based on the two; estimating the probability of a target flash loan attack based on the comprehensive price model; and determining that the flash loan transaction is a flash loan attack when the probability of a target flash loan attack is greater than a preset attack probability threshold. Using the embodiments of this application improves the accuracy of flash loan attack identification.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method for identifying flash loan attacks and a storage medium. Background Technology

[0002] A smart contract is a computer program that runs on a blockchain and possesses the decentralized, transparent, and immutable characteristics inherent to blockchain. In practical applications, because smart contracts on the blockchain are difficult to tamper with once deployed, vulnerabilities within the deployed contract cannot be fixed by modifying the code, making smart contracts easy targets for attacks.

[0003] Currently, the main method for detecting flash loan attacks is to analyze on-chain transactions, extract information such as contract addresses and events, and build a feature database based on this. This database is then used to analyze numerous transactions to determine whether the funds originate from the flash loan platform and to block them. However, this approach is prone to misidentifying many secure flash loan transactions, resulting in low accuracy. Therefore, improving the accuracy of flash loan attack detection is a pressing issue that needs to be addressed. Summary of the Invention

[0004] This application provides a method and storage medium for identifying flash loan attacks, which improves the accuracy of flash loan attack identification.

[0005] In a first aspect, embodiments of this application provide a method for identifying flash loan attacks, the method comprising:

[0006] By pre-setting an Ethereum full node to listen to the target blockchain, the first event log is obtained;

[0007] A first event token flow graph is constructed based on the first event log; the first event token flow graph includes n account addresses in the target blockchain used to receive or forward tokens; n is a positive integer;

[0008] Determine whether a flash loan transaction exists in the first event log based on the first event token flow graph;

[0009] When a flash loan transaction exists in the first event log, identify the target AMM node among the n account addresses that is at risk of flash loan attack.

[0010] Obtain the target smart contract bytecode and historical transaction data corresponding to the target AMM node;

[0011] A first price model corresponding to the target smart contract bytecode is determined; a second price model corresponding to the historical transaction data is determined; both the first price model and the second price model are mathematical expressions describing the price relationship of a preset trading token pair; the preset trading token pair includes a first token and a second token;

[0012] Determine the comprehensive price model based on the first price model and the second price model;

[0013] Based on the comprehensive price model, the probability that the flash loan transaction is a flash loan attack is estimated, and the target flash loan attack probability is obtained;

[0014] When the probability of a target flash loan attack is greater than a preset attack probability threshold, the flash loan transaction is determined to be a flash loan attack.

[0015] In a second aspect, embodiments of this application provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in the first aspect of embodiments of this application.

[0016] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing the steps in the first aspect of embodiments of this application.

[0017] Fourthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, the computer program being operable to cause a computer to perform some or all of the steps described in the first aspect of embodiments of this application. The computer program product may be a software installation package.

[0018] As can be seen, the flash loan attack identification method provided in this application integrates the first price model, which is the internal logic of the smart contract, and the second price model, which reflects the actual market situation, to obtain a comprehensive price model. This comprehensive price model can more accurately depict the overall performance of the token pair price under normal and abnormal conditions, avoiding the problem of one-sided judgment due to relying on a single model. This makes the assessment of whether the token pair price is abnormal more scientific and comprehensive, thereby improving the accuracy of flash loan attack judgment. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0020] Figure 1 This is a flowchart of a flash loan attack identification method provided in an embodiment of this application;

[0021] Figure 2This is a schematic diagram of the structure of a first event token flow graph provided in an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of the structure of a second event token flow graph provided in an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the structure of a target variable propagation tree provided in an embodiment of this application;

[0024] Figure 5 This is a schematic flowchart of a control flow subgraph provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0027] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, 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 listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0028] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0029] The electronic devices described in this application embodiment may include smartphones (such as Android phones, iOS phones, Windows Phones, etc.), tablet computers, handheld computers, laptops, video matrices, monitoring platforms, mobile internet devices (MIDs), or wearable devices, etc. The above are merely examples and not exhaustive, including but not limited to the above devices. Of course, the above electronic devices may also be servers, such as cloud servers.

[0030] The following will explain some of the technical terms used in this application:

[0031] Blockchain: A distributed, immutable recording technology that enables decentralized, trusted transactions and information storage by linking data together in the form of blocks.

[0032] An Ethereum full node is a node that completely stores all data on the Ethereum blockchain (including block headers, transaction data, smart contract code, etc.). It maintains the complete ledger of the blockchain and can independently verify the validity of transactions and blocks.

[0033] Decentralized Finance (DeFi) platforms are financial platforms based on blockchain technology. They enable financial transactions and services without intermediaries through smart contracts and cryptocurrencies, giving users greater autonomy and transparency.

[0034] Automated Market Maker (AMM): A trading protocol mechanism widely used on DeFi platforms. It automatically provides liquidity through smart contracts, replacing the traditional method of market makers manually providing liquidity in financial markets.

[0035] A smart contract is an automatically executed contract term deployed as code on a blockchain. It is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. Smart contracts allow for trusted transactions without a third party; these transactions are traceable and irreversible.

[0036] Smart contract bytecode: This is the machine-readable code form of a smart contract after it has been compiled. A smart contract is a contract with automatically executing terms that are deployed on the blockchain in the form of code. Bytecode is the intermediate or final form generated after this contract code has been compiled by a compiler and is used to execute within a blockchain virtual machine (such as the Ethereum Virtual Machine).

[0037] Flash loan attacks are malicious attacks that exploit the flash loan mechanism in DeFi platforms. Flash loans allow users to borrow funds (usually cryptocurrency) without collateral, repaying the principal and interest only at the end of the same blockchain transaction (within one block). Attackers use this mechanism to obtain large sums of money, manipulate market prices, or exploit smart contract vulnerabilities for illicit gains.

[0038] Please see Figure 1 , Figure 1 This is a flowchart of a flash loan attack identification method provided in an embodiment of this application. The method includes:

[0039] S101. By pre-setting an Ethereum full node to listen to the target blockchain, the first event log is obtained.

[0040] In this embodiment of the application, the preset Ethereum full node can be preset in advance or set by default.

[0041] In a specific embodiment, the types of events to be monitored can be determined based on the application scenario and content to be monitored of the target blockchain. Then, the events occurring in the target blockchain are monitored by a preset Ethereum full node to obtain a first event log. The first event log may include transaction events from one or more DeFi platforms in the target blockchain. For example, when monitoring flash loan-related events, it is necessary to monitor smart contract events related to lending operations, such as "LoanRequested", "LoanApproved", "LoanRepaid", "TransactionSent", and "TransactionReceived" event types. The target blockchain network is continuously monitored by the monitoring program in the preset Ethereum full node. Once a flash loan-related event occurs, the corresponding processing mechanism will be triggered. This processing mechanism may record the event information to a local file, send it to a remote server, or perform real-time analysis, thereby obtaining the first event log.

[0042] S102. Construct a first event token flow graph based on the first event log; the first event token flow graph includes n account addresses in the target blockchain used to receive or forward tokens; n is a positive integer.

[0043] In this embodiment, the first event log can be traversed to filter out logs related to token transactions, resulting in a second event log. Based on the second event log, a token flow graph is constructed with transaction addresses (i.e., the aforementioned n account addresses) as nodes and directed edges representing transaction relationships, resulting in the first event token flow graph. Generally, token transfers trigger an event with the theme "Transfer" on the target blockchain. The event log for this event contains information such as the sender, receiver, and the amount of tokens transferred. In the event token flow graph constructed in this embodiment, the sender's address is the starting point of the directed edge, and the receiver's address is the ending point. The first event token flow graph allows for tracking the flow of flash loan funds across various DeFi platforms, thereby accurately identifying flash loan attacks on DeFi platforms.

[0044] For example, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram of the structure of a first event token flow graph provided in an embodiment of this application, consisting of... Figure 2 It can be seen that Node 1, as the sender, sent tokens to Nodes 2 and 3 respectively; Node 2, as the sender, sent tokens to Nodes 4 and 6 respectively; Node 4, as the sender, sent tokens to Node 5; Node 5, as the sender, sent tokens to Node 6; Node 6, as the sender, sent tokens to Nodes 7 and 8 respectively; and Node 7, as the sender, sent tokens to Node 2. Nodes 1 through 8 are all account addresses in the target blockchain, with each node representing one account address.

[0045] S103. Determine whether there is a flash loan transaction in the first event log based on the first event token flow graph.

[0046] In this embodiment, the existence of flash loan transactions in the first event log can be determined based on the first event token flow graph. Specifically, each node on the first event token flow graph can be identified sequentially to determine whether it is a flash loan node. The identification of flash loan nodes is generally done by analyzing the historical transaction characteristics of the account address corresponding to the node, or by searching for the account address in the blockchain internet community to determine whether it provides flash loan lending services. If a node provides flash loan lending services, it can be determined that the node is a flash loan node, and thus, it can be determined that there are flash loan transactions in the first event log. Conversely, if none of the nodes on the first event token flow graph are flash loan nodes, it can be determined that there are no flash loan transactions in the first event log, that is, the probability of a target flash loan attack is 0, and no further steps are required.

[0047] S104. When a flash loan transaction exists in the first event log, identify the target AMM node among the n account addresses that is at risk of flash loan attack.

[0048] In this embodiment of the application, when a flash loan transaction exists in the first event log, risk analysis can be performed on n account addresses to identify target AMM nodes that may be at risk of flash loan attacks.

[0049] Optionally, step S104, determining the target AMM node among the n account addresses that poses a risk of flash loan attacks, may include the following steps:

[0050] A1. Obtain the historical transaction characteristics of each of the n account addresses to obtain n historical transaction characteristics;

[0051] A2. Based on the n historical transaction characteristics, determine the flash loan nodes and AMM nodes in the n account addresses to obtain i flash loan nodes and j AMM nodes; i and j are both natural numbers less than or equal to n, and the sum of i and j is less than or equal to n;

[0052] A3. Transform the first event token flow graph into a directed acyclic graph to obtain the second event token flow graph;

[0053] A4. Initialize the first dictionary; the key in the first dictionary is the node ID in the second event token flow graph, and the value represents the set of nodes upstream of the node that control the flow of its tokens to the current node; during initialization, the value corresponding to the entry node of the second event token flow graph is initialized to a set of nodes containing only its own node ID, and the value of the other nodes is set to the initial set V; the initial set V stores the node IDs of all nodes in the second event token flow graph.

[0054] A5. Based on the first dictionary, perform node identification on the second event token flow graph to obtain the target AMM node.

[0055] In this embodiment of the application, the historical transaction characteristics may include at least one of the following: transaction frequency characteristics, transaction amount characteristics, transaction object characteristics, transaction type characteristics, etc., which are not limited here; the node types include one of the following: flash loan node, AMM node, normal node, etc., which are not limited here.

[0056] In a specific embodiment, the historical transaction characteristics of each of the n account addresses can be obtained first, resulting in n historical transaction characteristics. Specifically, an Ethereum full node can be pre-set to obtain the historical transaction data of these n account addresses, resulting in n historical transaction data. Then, feature extraction can be performed on these n historical transaction data to obtain n feature data, i.e., n historical transaction characteristics. For example, historical transaction characteristics can be transaction frequency characteristics, calculating the number of transactions of nodes within a specific time period (such as daily, weekly, or monthly), analyzing the distribution of transaction frequency, such as whether there are peak or trough periods, thereby obtaining transaction frequency characteristics. Next, based on the n historical transaction characteristics, the flash loan nodes and AMM nodes in the n account addresses can be determined, resulting in i flash loan nodes and j AMM nodes. Specifically, a pre-stored mapping relationship between the historical transaction characteristics and node types can be used to determine the n node types corresponding to the n historical transaction characteristics, and then determine the nodes that are flash loan nodes and AMM nodes among these n node types, resulting in i flash loan nodes and j AMM nodes.

[0057] Next, the first event token flow graph can be transformed into a directed acyclic graph to obtain the second event token flow graph. Specifically, the cycles contained in the first event token flow graph can be determined to obtain f cycles, where f is a natural number. Then, the edges in these f cycles where the receiver is a flash loan node can be determined to obtain at least one edge. Removing this at least one edge will yield the second event token flow graph.

[0058] It should be explained that, in the embodiments of this application, a cycle in a directed acyclic graph refers to a cycle containing flash loan nodes. Figure 2 Taking the first event token flow graph as an example, assuming node 2 is a flash loan node, we need to determine the cycle of flash loan nodes included in the first event token flow graph (e.g., node 2 → node 6 → node 7 → node 2), and then determine the edge in the cycle where the receiver is a flash loan node, obtaining edge 72 (i.e., node 7 → node 2). Removing edge 72 yields the second event token flow graph, as shown below. Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of a second event token flow graph provided in an embodiment of this application.

[0059] Next, the first dictionary can be initialized; the key in the first dictionary is the node ID in the second event token flow graph (e.g., Figure 2 In the context of node 1 (where node ID is 1), value represents the set of nodes upstream of node 1 that control the flow of tokens to the current node. Figure 2Taking node 6 as an example, the value corresponding to node 6 is [1, 2, 6], excluding node 4. This is because although node 4 is upstream of node 6, node 4 cannot control the token flow of node 6, as node 2 can directly conduct token transactions with node 2 without going through node 4. The value can also be understood as the set of nodes that must be passed through for all paths from the entry node to this node. During initialization, the value corresponding to the entry node of the second event token flow graph is initialized to a set of nodes containing only its own node ID, and the values ​​of the remaining nodes are all set to the initial set V. The initial set V stores the node IDs of all nodes in the second event token flow graph. Finally, the node identification of the second event token flow graph can be performed according to the first dictionary to obtain the target AMM node.

[0060] In this way, by obtaining the historical transaction characteristics of n account addresses, i flash loan nodes and j AMM nodes can be determined. More monitoring and security protection resources can be concentrated on i flash loan nodes and j AMM nodes, instead of indiscriminately investing resources in all n nodes, thus improving resource utilization efficiency.

[0061] Optionally, A5, the step of identifying the target AMM node by analyzing the second event token flow graph based on the first dictionary may include the following steps:

[0062] The nodes in the second event token flow graph are traversed using a preset traversal method. For each node traversed, a preset risk identification operation is performed to obtain the target AMM node. The target AMM node includes at least one node.

[0063] In this embodiment of the application, the preset traversal method and the preset risk identification operation can both be preset in advance or defaulted.

[0064] In a specific embodiment, the preset traversal method can be the reverse post-order traversal of DFS. The second event token flow graph is traversed according to the preset traversal method. For each node traversed, a preset risk identification operation is performed on it, thereby obtaining the target AMM node.

[0065] Specifically, the preset risk identification operation includes:

[0066] B1. Get the first node v currently being traversed; get the first predecessor node set W corresponding to the first node v in the second event token flow graph; initialize the first set R to be an empty set, and the first set R is used to store the node set.

[0067] B2. Based on the first set R, perform a preset dictionary update operation on the first predecessor node set W to update the first dictionary and obtain the target dictionary;

[0068] B3. Extract the value corresponding to each of the j AMM nodes from the target dictionary to obtain j values;

[0069] B4. Determine the value of the j values ​​that contains the flash loan node, and obtain m values; m is a natural number less than or equal to j;

[0070] B5. Determine that the nodes corresponding to the m values ​​are nodes in the target AMM node.

[0071] In this embodiment of the application, the preset dictionary update operation can be preset in advance or defaulted.

[0072] In a specific embodiment, the first node v currently being traversed can be obtained first. Then, the set W of the first predecessor nodes corresponding to the first node v in the second event token flow graph can be obtained. Specifically, a predecessor node is a node that has an edge pointing from it to the first node v. For example, Figure 3 The predecessor node set of node 6 is [2, 5]. Next, a preset dictionary update operation can be performed on the first predecessor node set W based on the first set R to update the first dictionary and obtain the target dictionary. For example, Figure 3 The target dictionary corresponding to the second event token flow graph is {1: [1], 2: [1, 2], 3: [1, 3], 4: [1, 2, 4], 5: [1, 2, 4, 5], 6: [1, 2, 6], 7: [1, 2, 6, 7], 8: [1, 2, 6, 8]}. Then, the value corresponding to each of the j AMM nodes can be extracted from the target dictionary to obtain j values. Find the values ​​that contain flash loan nodes among the j values ​​to obtain m values. Specifically, the nodes in each of the j values ​​can be checked to match with i flash loan nodes. If any flash loan node is found in a certain value, then this value is the value containing flash loan nodes, thus obtaining m values. Finally, the nodes corresponding to these m values ​​can be determined according to the target dictionary to obtain m nodes, that is, the target AMM nodes include these m nodes.

[0073] In this way, the relationships between nodes are recorded in a structured manner through the first dictionary. By updating the dictionary, this record of node relationships can be continuously improved and optimized. In complex blockchain networks and transaction scenarios, accurate node relationship data helps to conduct subsequent analysis more efficiently, thereby improving data processing efficiency. In addition, once the target AMM node is identified, it can be monitored and managed in a targeted manner, strengthening transaction audits of these nodes, setting up risk warning mechanisms, etc., thereby ensuring the security and stability of blockchain transactions.

[0074] Optionally, the preset dictionary update operation may include the following steps:

[0075] Nodes are retrieved from the first set of predecessor nodes W in a preset order. For each node retrieved, a first dictionary update operation is performed on it to obtain a second dictionary.

[0076] Check whether the second dictionary is consistent with the first dictionary;

[0077] If they are inconsistent, then obtain the next node of the first node v and perform the preset dictionary update operation on the next node;

[0078] If they match, the target dictionary is determined based on the second dictionary, and the preset dictionary update operation is stopped.

[0079] The first dictionary update operation includes the following steps:

[0080] C1. Obtain the first node ID corresponding to the first predecessor node w; the first predecessor node w is the node taken from the first predecessor node set W at the current time;

[0081] C2. Extract the value corresponding to the first node ID from the first dictionary, and denote it as the first set DV;

[0082] C3. When the first set R is an empty set, R = DV;

[0083] C4. When the first set R is not empty, R = R∩DV;

[0084] C5. Add the first node v to the first set R to obtain the target set;

[0085] C6. Update the value of the first node v in the first dictionary with the target set.

[0086] In this embodiment, the preset order can be preset in advance or be the default.

[0087] In a specific embodiment, nodes can be retrieved from the first predecessor node set W in a preset order. For each retrieved node, a first dictionary update operation is performed. The first dictionary update operation includes: First, the first node ID of the first predecessor node w can be queried from a preset database, or the first node ID can be obtained by monitoring the first predecessor node w through a preset Ethereum full node. Then, the value corresponding to the first node ID can be extracted from the first dictionary, denoted as the first set DV. When the first set R is empty, i.e., when the preset dictionary update operation is performed for the first time, set R = DV. When the first set R is not empty, i.e., when the preset dictionary update operation is not performed for the first time, set R = R∩DV. Next, the first node v can also be added to the first set R to obtain the target set. The value of the first node v in the first dictionary is replaced with the target set.

[0088] After performing a first dictionary update operation on all nodes in the first predecessor node set W, the second dictionary is obtained. The second dictionary is then checked for consistency with the first dictionary. Specifically, the first key set of the first dictionary and the second key set of the second dictionary are obtained separately, and their values ​​are checked for equality. If they are equal, the values ​​corresponding to each key are further checked for equality. If both are equal, the dictionary update is complete, meaning the second dictionary is consistent with the first dictionary. Otherwise, the dictionary update is incomplete, and the second dictionary is inconsistent with the first dictionary.

[0089] If they are inconsistent, then obtain the next node of the first node v in the preset traversal method, and perform a preset dictionary update operation on the next node;

[0090] If they match, the second dictionary is directly selected as the target dictionary, and the preset dictionary update operation is stopped.

[0091] In this way, by obtaining the first node ID corresponding to each predecessor node w, and then extracting the corresponding value (i.e., the first set DV) from the first dictionary, we can accurately obtain the information of other nodes associated with the current predecessor node, thereby constructing a complete network of relationships between nodes, obtaining the target dictionary, and providing data support for subsequent in-depth analysis of the dependencies, control, and influence relationships between nodes.

[0092] S105. Obtain the target smart contract bytecode and historical transaction data corresponding to the target AMM node.

[0093] In this embodiment of the application, an Ethereum full node can be preset to obtain the target smart contract bytecode corresponding to the target AMM node. Specifically, the smart contract address of the target AMM node can be obtained first, and the target smart contract bytecode can be obtained through the RPC (Remote Procedure Call) method. The AMM node ID corresponding to the target AMM node can also be obtained. The transaction data associated with the AMM node ID can be queried in the preset database by the preset Ethereum full node, thereby obtaining the historical transaction data.

[0094] S106. Determine the first price model corresponding to the target smart contract bytecode; determine the second price model corresponding to the historical transaction data; both the first price model and the second price model are mathematical expressions describing the price relationship of a preset transaction token pair; the preset transaction token pair includes a first token and a second token.

[0095] In this embodiment, a first price model can be obtained by analyzing the bytecode of the target smart contract. Then, a second price model corresponding to historical transaction data can be determined. Specifically, transaction records involving the first and second tokens can be filtered from historical transaction data to obtain token pair transaction data. This data can be preprocessed (e.g., removing outliers, filling in missing values, etc.) to obtain processed token pair transaction data. A preset fitting method is selected to fit the token pair transaction data, and the fitted parameter values ​​are obtained. Then, a nonlinear fitting curve equation for the preset token pair is obtained, which is used as the second price model. The preset fitting method can include at least one of the following: linear regression fitting method, multinomial regression method, support vector regression fitting method, etc., which are not limited here. For example, assuming that the token pair transaction data is fitted using a multinomial regression method, the fitted curve equation (i.e., the second price model) is:

[0096] u(x)=y=0.138634+x*1.519267+x*x*0.003977;

[0097] Where u(x) represents the second price model, y represents the second token, and x represents the first token.

[0098] Thus, by using the first price model and the second price model to describe the price relationship of the pre-defined trading token pair from the perspectives of the contract's internal logic and actual market behavior, respectively, a more comprehensive assessment of the rationality and stability of the price relationship can be achieved. Simultaneously, it allows for a more accurate identification of potential trading risks, such as price manipulation risk and contract execution risk.

[0099] Optionally, step S106, determining the first price model corresponding to the target smart contract bytecode, may include the following steps:

[0100] D1. Decompile the target smart contract bytecode to obtain the target control flow graph;

[0101] D2. Obtain the external function name and exchange parameters for the token exchange from the target ABI file corresponding to the target smart contract bytecode;

[0102] D3. Calculate the function signature based on the preset hash function, the external function name, and the exchange parameters to obtain the target function signature;

[0103] D4. Determine the entry node in the target control flow graph based on the objective function signature;

[0104] D5. Starting from the entry node, traverse the target control flow graph to obtain the traversed control flow subgraph;

[0105] D6. Inversely deduce the first price model based on the control flow subgraph.

[0106] In this embodiment, the preset hash function can be preset in advance or defaulted.

[0107] In a specific embodiment, the target smart contract bytecode can be decompiled to obtain the target control flow graph. Specifically, Ethereum smart contract decompilation technology can be used to construct the target control flow graph starting from the target smart contract bytecode (a string sequence composed of hexadecimal numbers).

[0108] It's important to explain that decompilation technology involves reverse-engineering the executable program of another's software to deduce its execution process. A control flow graph is a directed graph composed of basic blocks (the longest sequence of instructions with a single entry and exit point) as nodes and the transition relationships between these basic blocks as edges. By traversing the target control flow graph, all execution paths of the smart contract can be analyzed.

[0109] Next, the external function name and exchange parameters for the token exchange can be obtained from the target ABI file corresponding to the target smart contract bytecode. Specifically, first, the target smart contract corresponding to the target smart contract bytecode can be identified, and the contract address of the target smart contract can be obtained. Then, the target ABI file can be obtained from the preset database using a preset Ethereum full node or Ethereum blockchain explorer based on the contract address. Next, a suitable parsing tool (e.g., Python) can be selected to parse the target ABI file to obtain the external function name and exchange parameters. Specifically, the external function name for the token exchange often contains certain keywords, such as "swap", "exchange", and "convert". The external function name (name field) related to the token exchange can be filtered out by checking whether it contains these keywords. Then, the input parameters of the function corresponding to the external function name, i.e., the exchange parameters, can be obtained.

[0110] Furthermore, the target function signature is obtained by calculating the function signature based on the preset hash function (e.g., SHA3 hash function), the external function name, and the exchange parameters. Specifically, the external function name and exchange parameters can be concatenated together and then input into the preset hash function for calculation to obtain the target function signature. For example, assuming the external function name is x11 and the exchange parameters are uint a and uint b, concatenation yields "x11(uint, uint)", and Signature = H("x11(uint, uint)"). Here, "x11(uint, uint)" represents the input, H() represents the preset hash function, and Signature represents the target function signature. Next, the entry node in the target control flow graph can be determined based on the target function signature. Specifically, the function signature of each node in the target control flow graph can be compared with the target function signature. If they match, the node is the entry node. Then, starting from the entry node, the target control flow graph can be traversed to obtain the traversed control flow subgraphs. Finally, the first price model can be inferred from the control flow subgraphs.

[0111] Thus, by traversing the control flow graph starting from the entry node, the resulting control flow subgraph is a more detailed graphical representation focusing on the execution of the token exchange function. It filters out other contract logic unrelated to this function's execution, allowing for a more detailed and in-depth analysis of the code execution path and data flow related to the token exchange function, thereby improving data analysis efficiency.

[0112] Optionally, the step of inferring the first price model from the control flow subgraph may include the following steps:

[0113] E1. Initialize the initial variable model VTable-init; the initial variable model VTable-init is a table used to store tuples (var, val), where var is the unique identifier of the variable and val is the possible value of the variable;

[0114] E2. Initialize stack S to be empty, and then push the first element (VTable-init, entry) onto stack S; where entry is the node address of the entry node;

[0115] E3. Perform the preset variable propagation tree construction operation to obtain the target variable propagation tree;

[0116] E4. Starting from the leaf node of the target variable propagation tree, the parent node is expressed by the child node, and the process is iterated until the root node y of the target variable propagation tree is reached. The variable y corresponding to the root node y is expanded into the expression of the leaf node in the target variable propagation tree to obtain the target expression.

[0117] E5. Replace the variables in the target output amount_out based on the target expression to obtain the first price model.

[0118] In this embodiment, the preset variable propagation tree construction operation can be preset in advance or defaulted; val has four types: the symbol of other variables, the expression composed of other variables, the constant value, and the unknown value.

[0119] It should be explained that this application determines the target output amount_out by identifying LOG instructions in the control flow subgraph, thereby obtaining the variable y. Therefore, the above-mentioned step of inferring the first price model from the control flow subgraph is only performed after it is determined that there is a node containing LOG instructions in the control flow subgraph. Conversely, if there is no node containing LOG instructions in the control flow subgraph, it means that the price model cannot be derived from the control flow subgraph, and that is, there is no need to perform the above-mentioned step of inferring the first price model from the control flow subgraph.

[0120] In a specific embodiment, the initial variable model VTable-init can be initialized to be empty or to a preset variable model. Then, the stack S can be initialized to be empty, and then the first element (VTable-init, entry) is pushed onto the stack S. Next, the preset variable propagation tree construction operation can be performed to obtain the target variable propagation tree. Then, starting from the leaf node of the target variable propagation tree, the parent node is expressed by using the child node, and the iteration is performed until the root node y of the target variable propagation tree. The variable y corresponding to the root node y is expanded into the expression of the leaf node in the target variable propagation tree to obtain the target expression.

[0121] To illustrate, let's assume that the initial variable model VTable-init is a preset variable model, as shown in Table 1:

[0122] Table 1

[0123] x null r_in null r_out null

[0124] The initial variable model VTable-init is updated based on the node content in the control flow subgraph to obtain the final variable model, as shown in Table 2:

[0125] Table 2

[0126]

[0127]

[0128] Based on Table 2, a propagation tree for the target variable can be constructed. For details, please refer to [reference needed]. Figure 4 , Figure 4 This is a schematic diagram of the structure of a target variable propagation tree provided in an embodiment of this application, which can be seen from... Figure 4 Starting from the leaf nodes of the target variable propagation tree, the parent node is expressed using child nodes. For example, if the leaf node of node v1 is 997, then v1 can be represented by 997. Similarly, if the child nodes of node v2 are nodes x and v1, then v2 = x * v1 = x * 997. The iteration continues until the root node y of the target variable propagation tree. The variable y corresponding to the root node y is expanded into the expression of the leaf nodes in the target variable propagation tree to obtain the target expression. Specifically, the root node y is node v7, and the target expression is v7 = (RY * x * 997) / (RX * 1000 + x * 997); where RY represents the quantity of the second token in the target blockchain at the current moment, and RX represents the quantity of the first token in the target blockchain at the current moment.

[0129] Finally, the first price model can be obtained by replacing the variables in the target output amount_out based on the target expression. It should be explained that the target output amount_out is the root node of the target variable propagation tree, that is, the target output amount_out is v7. Then, the first price model is amount_out = f(x) = (RY*x*997) / (RX*1000+x*997).

[0130] In this way, by starting from the leaf node and using the child nodes to express the parent node, iterating step by step to the root node, it is equivalent to starting from the most basic and simple elements and gradually building complex variable relationship expressions. This clearly shows how variables are nested and interact with each other, making the relationship between variables more transparent, intuitive and easy to understand.

[0131] Optionally, the preset variable propagation tree construction operation may include the following steps:

[0132] S11. Determine whether the stack S is empty. If it is empty, stop the execution of the preset variable propagation tree construction operation and use the newly generated variable propagation tree as the target variable propagation tree. If it is not empty, proceed to step S12.

[0133] S12. Take the top element from the stack S to obtain the target element (VTable, node). Determine the target node based on the node address node. Update the variable model VTable based on the content in the target node to obtain the updated variable model VTable-new. VTable represents the variable model before entering the target node.

[0134] S13. Determine the node containing the LOG instruction in the control flow subgraph to obtain the first control flow graph node, obtain the LOG parameter data of the LOG instruction in the first control flow graph node, and identify the target output amount_out from the LOG parameter data;

[0135] S14. Determine the variable y corresponding to the target output amount_out in the control flow subgraph;

[0136] S15. Construct a variable propagation tree with the variable y as the root node based on the variable model stored in the stack S to obtain the first variable propagation tree;

[0137] S16. Push the second element (VTable-new, node-next) onto the stack S, and jump to step S11; where node-next is the node address of the successor node of node.

[0138] In this embodiment, it can be determined first whether stack S is empty. If it is empty, it means that the variable propagation tree has been built. Then, the preset variable propagation tree building operation is stopped, and the newly generated variable propagation tree is used as the target variable propagation tree. If it is not empty, the process jumps to the above step S12.

[0139] If step S12 is executed, the top element of stack S is removed to obtain the target element (VTable, node). Then, the node address node can be determined to correspond to the node in the control flow subgraph, thus obtaining the target node. The variable model VTable is updated based on the content of the target node, resulting in the updated variable model VTable-new. Further, the nodes containing LOG instructions in the control flow subgraph can be queried to obtain the first control flow graph node. The LOG parameter data of the LOG instructions in the first control flow graph node is obtained, and the target output amount_out is identified from the LOG parameter data. For example, assuming the LOG instruction is "LOG SWAP(……,v7,……)”, from which the LOG parameter data “(……,v7,……)” can be extracted, and it can be seen that the target output amount_out is v7; then, it can be determined that the variable y corresponding to the target output amount_out in the control flow subgraph is v7; then, according to the variable model stored in stack S, a variable propagation tree with variable y as the root node can be constructed to obtain the first variable propagation tree; push the second element (VTable-new, node-next) onto stack S, and jump to step S11.

[0140] It should be noted that a node may have more than one successor node, so the second element pushed onto stack S in step S16 may also have more than one occurrence; please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic flowchart of a control flow subgraph provided in an embodiment of this application, to... Figure 5 Let's take the control flow subgraph in the diagram as an example to illustrate S16:

[0141] Initially, control flow graph node ① (i.e., the entry node) is pushed onto the stack, and the first element (VTable-init, entry) is pushed onto stack S. Then, the first element is popped from the stack, and the variable model VTable-init is updated according to the content of control flow graph node ①, resulting in variable model VTable1. Next, the subsequent nodes of control flow graph node ①, control flow graph nodes ② and ③, are pushed onto the stack, i.e., elements (VTable1, n1) and (VTable1, n2) are pushed onto stack S in sequence, where n1 is the address of control flow graph node ② and n2 is the address of control flow graph node ③. Then, element (VTable1, n2) is popped from the stack, and the variable model VTable1 is updated according to the content of control flow graph node ③, resulting in variable model VT. Since control flow graph node ③ has no subsequent nodes, no new elements are added to stack S. Then, element (VTable1, n1) is popped from the stack, and variable model VTable1 is updated according to the content of control flow graph node ② to obtain variable model VTable3. Its subsequent node ④ is pushed onto the stack, that is, element (VTable3, n3) is pushed onto stack S, where n3 is the address of control flow graph node ④. Next, element (VTable3, n3) can be popped from the stack, and variable model VTable3 is updated according to the content of control flow graph node ④ to obtain variable model VTable4. Since control flow graph node ④ has no subsequent nodes, no new elements are added to stack S. At this time, stack S is empty, indicating that the control flow subgraph has been traversed.

[0142] Optionally, updating the variable model VTable based on the content in the target node to obtain the updated variable model VTable-new may include the following steps:

[0143] F1. Obtain the target statement type of the target node; the target statement type includes one of the following: declaration statement, assignment statement;

[0144] F2. Determine the target variable model update operation corresponding to the target statement type;

[0145] F3. Update the variable model VTable according to the target variable model update operation to obtain the updated variable model VTable-new.

[0146] In this embodiment of the application, the target statement type may include one of the following: declaration statement, assignment statement, conditional statement, loop statement, etc., which are not limited here.

[0147] In a specific embodiment, the target statement type of the target node can be obtained; then, the target variable model update operation corresponding to the target statement type can be determined. Specifically, a preset mapping relationship between statement types and variable model update operations can be stored in advance, and the target variable model update operation corresponding to the target statement type can be determined based on this mapping relationship; then, the variable model VTable can be updated according to the target variable model update operation to obtain the updated variable model VTable-new, for example:

[0148] (a) If the target statement type is a declaration statement and the variable v1 is declared, then add (v1, unknown value) to the variable model VTable, where v1 is the variable name.

[0149] (b) If the target statement type is an assignment statement that assigns a value to variable v1, then find the value val corresponding to var as the left-hand side of the assignment statement from the variable model VTable, and update it to the right-hand side of the assignment statement. For example, suppose there is an assignment statement "v1 = b + 1", where v1 is var and b + 1 is val, where var represents the left-hand side of the equals sign in the assignment statement and val represents the right-hand side of the equals sign; then, find the row in the variable model VTable where var is v1, and update the val column with b + 1.

[0150] Optionally, in one embodiment, step S15, constructing a variable propagation tree with the variable y as the root node based on the variable model stored in the stack S to obtain the first variable propagation tree, may include the following steps:

[0151] We can obtain the target variable model corresponding to stack S. Specifically, we can obtain which variable models have been stored in stack S. Then, we can remove duplicate data in these variable models and combine the remaining data into a variable model, which is the target variable model. Next, we initialize the binary set TreeE to be an empty set; we initialize the variable stack VarS to be empty; and then, we push the variable y onto the variable stack VarS.

[0152] S21. Take variable v' from the variable stack VarS and read the val value of var = v' from the target variable model;

[0153] S22. If the value of val is a constant, then the first set of elements (v', val) is added to the set of binary pairs TreeE, which means that there is an edge from v' to val in the variable propagation tree.

[0154] S23. If the value of val is a function expression, then the function expression is scanned from left to right, and the variable v_e and constant c contained therein are collected. The second group of elements (v', v_e) and the third group of elements (v', c) are added to the binary set TreeE in sequence, and the variable v_e is pushed onto the variable stack VarS.

[0155] S23. Determine whether the variable stack VarS is empty. If it is empty, determine the first variable propagation tree based on the set of tuples TreeE. If it is not empty, proceed to step S21.

[0156] In this embodiment of the application, the top element of the variable stack VarS, i.e., variable v', can be retrieved. Then, the val value of var = v' can be read from the target variable model, thereby obtaining the value of variable v'.

[0157] If val is a constant value, then the first set of elements (v', val) is added to the set TreeE, which means that there is an edge from v' to val in the variable propagation tree;

[0158] If the value of val is a function expression, then the function expression is scanned from left to right, collecting the variables v_e and constant c contained therein. The second set of elements (v', v_e) and the third set of elements (v', c) are added to the binary tuple set TreeE in turn, and the variable v_e is pushed onto the variable stack VarS. For example, suppose a function expression is v2 = x * v1. This function expression does not contain a constant, but has two variables x and v1. Then the elements (v', x) and (v', v1) can be added to the binary tuple set TreeE, and these two variables x and v1 can also be pushed onto the variable stack VarS.

[0159] Determine if the variable stack VarS is empty. If empty, determine the first variable propagation tree based on the set of tuples TreeE. Specifically, each element in TreeE represents an edge in the first variable propagation tree. In the element (v', x), v' is the parent node and x is the child node. For example, please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram of the structure of a target variable propagation tree provided in an embodiment of this application. Figure 4 The set of binary pairs corresponding to the target variable propagation tree in the model is {(v7, v3), (v7, v6), (v3, v2), (v3, r_out), (v2, x), (v2, v1), (v1, 997), (v6, v5), (v6, v2), (v5, r_in), (v5, v4), (v4, 1000), (v2, x), (v2, v1), (v1, 997)}.

[0160] If not empty, proceed to step S21.

[0161] Thus, by constructing a variable propagation tree, the dependencies between variables can be clearly shown, that is, how the value of a variable depends on other variables or constants, thereby providing strong data support for the derivation of price models.

[0162] S107. Determine the comprehensive price model based on the first price model and the second price model.

[0163] In this embodiment of the application, the preset weight pairs can be preset in advance or defaulted.

[0164] In a specific embodiment, a combined price model can be obtained by combining the first price model and the second price model using preset weights, as follows:

[0165] v(x)=a*f(x)+b*u(x), 0 <a<1,0<b<1,a+b=1;

[0166] The preset weight pair is (a, b), where a is the weight corresponding to the first price model, b is the weight corresponding to the second price model, f(x) represents the first price model, u(x) represents the second price model, and v(x) represents the comprehensive price model.

[0167] S108. Based on the comprehensive price model, estimate the probability that the flash loan transaction is a flash loan attack, and obtain the target flash loan attack probability.

[0168] In this embodiment, the token reserves RX_b and RY_b of a preset transaction token pair before the flash loan transaction, and the reserves RX_a and RY_a after the flash loan transaction, can be obtained through a preset Ethereum full node. The change in the exchange rate k of the transaction pool reserves can then be calculated using the following formula:

[0169] k=abs(RX_a / RY_a–RX_b / RY_b);

[0170] The abs() function represents taking the absolute value. Next, the composite price model v(x) can be used to predict the exchange rate trend of the flash loan transaction pair. Specifically, the derivative v(x) can be obtained by taking the derivative v'(x), and then RX_a and RY_a can be substituted into the derivative v'(x) to calculate the exchange rate trend.

[0171] s = w(x) = abs(v'(x));

[0172] Where s represents the exchange rate trend change value, s can be used to measure the impact of the current transaction on the exchange rate between the first and second tokens. Then, the probability of a target flash loan attack can be determined based on the exchange rate change k of the transaction pool stock and the exchange rate trend change value s. The specific calculation formula is as follows:

[0173] p = w_s*s + w_k*k;

[0174] Where p represents the probability of a flash loan attack, w_s is the first preset weight, and w_k is the second preset weight; both the first and second preset weights can be preset in advance or defaulted.

[0175] To illustrate, suppose a = 0.8 and b = 0.2, then the comprehensive price model is as follows:

[0176] v(x)=0.8*((RY*x*997) / (RX*1000+x*997))+0.2*(0.138634+x*1.519267+x*x*0.003977).

[0177] Before the transaction, RX_b = 60000, RY_b = 100000, RX_a = 60078.763, RY_a = 99868.900; according to the above formula for calculating k, k = 0.001576 can be calculated; assuming x = 79, the derivative of the above comprehensive price model v(x) is: 0.8*(-994009*RY*x / (1000*RX+997*x)^2+997*RY / (1000*RX+997*x))+0.2*(1.519267+2*x*0.003977);

[0178] Substituting RX_a and RY_a into v'(x) yields s = 1.634733; assuming w_s = 0.7 and w_k = 0.3, the probability p of a flash loan attack can be calculated based on k and s, using the following formula:

[0179] p=w_s*s+w_k*k=1.1447859.

[0180] S109. When the probability of a target flash loan attack is greater than a preset attack probability threshold, the flash loan transaction is determined to be a flash loan attack.

[0181] In this embodiment of the application, the preset attack probability threshold can be preset in advance or set by default.

[0182] In a specific embodiment, when the target flash loan attack probability is greater than a preset attack probability threshold, the flash loan transaction is determined to be a flash loan attack, and a corresponding target alarm operation is executed. For example, a preset mapping relationship between flash loan attack probabilities and alarm operations can be stored in advance. Based on this mapping relationship, the target alarm operation corresponding to the target flash loan attack probability is determined. For example, assuming the preset attack probability threshold is 0.5, the above-mentioned target flash loan attack probability p is 1.1447859. 1.1447859 is less than 0.5, indicating that the change in the preset transaction token pair is not significant, and it can be determined that this flash loan transaction is not a flash loan attack.

[0183] As can be seen, the flash loan attack identification method provided in this application integrates the first price model, which is the internal logic of the smart contract, and the second price model, which reflects the actual market situation, to obtain a comprehensive price model. This comprehensive price model can more accurately depict the overall performance of the token pair price under normal and abnormal conditions, avoiding the problem of one-sided judgment due to relying on a single model. This makes the assessment of whether the token pair price is abnormal more scientific and comprehensive, thereby improving the accuracy of flash loan attack judgment.

[0184] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device includes a processor, a memory, a communication interface, and one or more programs. The processor, memory, and communication interface are interconnected via a bus. The one or more programs are stored in the memory and configured to be executed by the processor. In this embodiment, the programs include instructions for performing the following steps:

[0185] By pre-setting an Ethereum full node to listen to the target blockchain, the first event log is obtained;

[0186] A first event token flow graph is constructed based on the first event log; the first event token flow graph includes n account addresses in the target blockchain used to receive or forward tokens; n is a positive integer;

[0187] Determine whether a flash loan transaction exists in the first event log based on the first event token flow graph;

[0188] When a flash loan transaction exists in the first event log, identify the target AMM node among the n account addresses that is at risk of flash loan attack.

[0189] Obtain the target smart contract bytecode and historical transaction data corresponding to the target AMM node;

[0190] A first price model corresponding to the target smart contract bytecode is determined; a second price model corresponding to the historical transaction data is determined; both the first price model and the second price model are mathematical expressions describing the price relationship of a preset trading token pair; the preset trading token pair includes a first token and a second token;

[0191] Determine the comprehensive price model based on the first price model and the second price model;

[0192] Based on the comprehensive price model, the probability that the flash loan transaction is a flash loan attack is estimated, and the target flash loan attack probability is obtained;

[0193] When the probability of a target flash loan attack is greater than a preset attack probability threshold, the flash loan transaction is determined to be a flash loan attack.

[0194] Optionally, regarding the determination of the target AMM node among the n account addresses that poses a risk of flash loan attacks, the above procedure further includes instructions for performing the following steps:

[0195] Obtain the historical transaction characteristics of each of the n account addresses to obtain n historical transaction characteristics;

[0196] Based on the n historical transaction characteristics, the flash loan nodes and AMM nodes in the n account addresses are determined, resulting in i flash loan nodes and j AMM nodes; i and j are both natural numbers less than or equal to n, and the sum of i and j is less than or equal to n;

[0197] The first event token flow graph is transformed into a directed acyclic graph to obtain the second event token flow graph;

[0198] Initialize the first dictionary; the key in the first dictionary is the node ID in the second event token flow graph, and the value represents the set of nodes upstream of the node that control the flow of its tokens to the current node; during initialization, the value corresponding to the entry node of the second event token flow graph is initialized to a set of nodes containing only its own node ID, and the value of the other nodes is set to the initial set V; the initial set V stores the node IDs of all nodes in the second event token flow graph;

[0199] The target AMM node is obtained by identifying nodes in the second event token flow graph based on the first dictionary.

[0200] Optionally, in the step of identifying nodes in the second event token flow graph based on the first dictionary to obtain the target AMM node, the above procedure further includes instructions for performing the following steps:

[0201] The nodes in the second event token flow graph are traversed using a preset traversal method. For each node traversed, a preset risk identification operation is performed to obtain the target AMM node. The target AMM node includes at least one node.

[0202] The preset risk identification operation specifically includes:

[0203] Get the first node v currently being traversed; get the first predecessor node set W corresponding to the first node v in the second event token flow graph; initialize the first set R as an empty set, and the first set R is used to store the node set;

[0204] Based on the first set R, a preset dictionary update operation is performed on the first predecessor node set W to update the first dictionary and obtain the target dictionary;

[0205] Extract the value corresponding to each of the j AMM nodes from the target dictionary to obtain j values;

[0206] Determine the value containing the flash loan node among the j values ​​to obtain m values; m is a natural number less than or equal to j.

[0207] The nodes corresponding to the m values ​​are determined to be nodes in the target AMM node.

[0208] Optionally, the preset dictionary update operation includes:

[0209] Nodes are retrieved from the first set of predecessor nodes W in a preset order. For each node retrieved, a first dictionary update operation is performed on it to obtain a second dictionary.

[0210] Check whether the second dictionary is consistent with the first dictionary;

[0211] If they are inconsistent, then obtain the next node of the first node v and perform the preset dictionary update operation on the next node;

[0212] If they match, the target dictionary is determined based on the second dictionary, and the preset dictionary update operation is stopped.

[0213] The first dictionary update operation includes:

[0214] Obtain the first node ID corresponding to the first predecessor node w; the first predecessor node w is the node taken from the first predecessor node set W at the current time;

[0215] Extract the value corresponding to the first node ID from the first dictionary, and denote it as the first set DV;

[0216] When the first set R is empty, R = DV;

[0217] When the first set R is not empty, R = R∩DV;

[0218] Add the first node v to the first set R to obtain the target set;

[0219] Update the value of the first node v in the first dictionary with the target set.

[0220] Optionally, in determining the first price model corresponding to the target smart contract bytecode, the above procedure further includes instructions for performing the following steps:

[0221] The target smart contract bytecode is decompiled to obtain the target control flow graph;

[0222] Obtain the external function name and exchange parameters for the token exchange from the target ABI file corresponding to the target smart contract bytecode;

[0223] The target function signature is obtained by calculating the function signature based on the preset hash function, the external function name, and the exchange parameters;

[0224] The entry node in the target control flow graph is determined based on the objective function signature;

[0225] Starting from the entry node, traverse the target control flow graph to obtain the traversed control flow subgraph;

[0226] The first price model is derived by inversely based on the control flow subgraph.

[0227] Optionally, in reversing the first price model based on the control flow subgraph, the above procedure further includes instructions for performing the following steps:

[0228] Initialize the initial variable model VTable-init; the initial variable model VTable-init is a table used to store binary tuples (var, val), where var is the unique identifier of the variable and val is the possible value of the variable;

[0229] Initialize stack S to be empty, and then push the first element (VTable-init, entry) onto stack S; where entry is the node address of the entry node;

[0230] Perform the preset variable propagation tree construction operation to obtain the target variable propagation tree;

[0231] Starting from the leaf node of the target variable propagation tree, the parent node is expressed by using the child node, and the process is iterated until the root node y of the target variable propagation tree is reached. The variable y corresponding to the root node y is expanded into the expression of the leaf node in the target variable propagation tree to obtain the target expression.

[0232] The first price model is obtained by replacing the variables in the target output amount_out based on the target expression.

[0233] Optionally, the preset variable propagation tree construction operation includes:

[0234] S11. Determine whether the stack S is empty. If it is empty, stop the execution of the preset variable propagation tree construction operation and use the newly generated variable propagation tree as the target variable propagation tree. If it is not empty, proceed to step S12.

[0235] S12. Take the top element from the stack S to obtain the target element (VTable, node). Determine the target node based on the node address node. Update the variable model VTable based on the content in the target node to obtain the updated variable model VTable-new. VTable represents the variable model before entering the target node.

[0236] S13. Determine the node containing the LOG instruction in the control flow subgraph to obtain the first control flow graph node, obtain the LOG parameter data of the LOG instruction in the first control flow graph node, and identify the target output amount_out from the LOG parameter data;

[0237] S14. Determine the variable y corresponding to the target output amount_out in the control flow subgraph;

[0238] S15. Construct a variable propagation tree with the variable y as the root node based on the variable model stored in the stack S to obtain the first variable propagation tree;

[0239] S16. Push the second element (VTable-new, node-next) onto the stack S, and jump to step S11; where node-next is the node address of the successor node of node.

[0240] Optionally, in updating the variable model VTable based on the content in the target node to obtain the updated variable model VTable-new, the above procedure further includes instructions for performing the following steps:

[0241] Obtain the target statement type of the target node; the target statement type includes one of the following: declaration statement, assignment statement;

[0242] Determine the target variable model update operation corresponding to the target statement type;

[0243] The variable model VTable is updated according to the target variable model update operation to obtain the updated variable model VTable-new.

[0244] Optionally, in constructing a variable propagation tree with the variable y as the root node based on the variable model stored in the stack S to obtain the first variable propagation tree, the above program further includes instructions for performing the following steps:

[0245] Obtain the target variable model corresponding to the stack S;

[0246] The binary tuple set TreeE is initialized to an empty set; the binary tuple set TreeE is used to store variable trees;

[0247] The variable stack VarS is initialized to be empty. Then, the variable y is pushed onto the variable stack VarS. The variable stack VarS is used to store variables to be processed.

[0248] S21. Take variable v' from the variable stack VarS and read the val value of var = v' from the target variable model;

[0249] S22. If the value of val is a constant, then the first set of elements (v', val) is added to the set of binary pairs TreeE, which means that there is an edge from v' to val in the variable propagation tree.

[0250] S23. If the value of val is a function expression, then the function expression is scanned from left to right, and the variable v_e and constant c contained therein are collected. The second group of elements (v', v_e) and the third group of elements (v', c) are added to the binary set TreeE in sequence, and the variable v_e is pushed onto the variable stack VarS.

[0251] S23. Determine whether the variable stack VarS is empty. If it is empty, determine the first variable propagation tree based on the set of tuples TreeE. If it is not empty, proceed to step S21.

[0252] In specific implementations, the electronic device described in the embodiments of the present invention may also perform some or all of the steps of any of the methods described in the above method embodiments, which will not be repeated here.

[0253] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0254] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0255] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0256] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0257] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0258] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0259] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0260] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0261] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for identifying flash loan attacks, characterized in that, The method includes: By pre-setting an Ethereum full node to listen to the target blockchain, the first event log is obtained; A first event token flow graph is constructed based on the first event log; the first event token flow graph includes n account addresses in the target blockchain used to receive or forward tokens; n is a positive integer; Determine whether a flash loan transaction exists in the first event log based on the first event token flow graph; When a flash loan transaction exists in the first event log, identify the target AMM node among the n account addresses that is at risk of flash loan attack. Obtain the target smart contract bytecode and historical transaction data corresponding to the target AMM node; A first price model corresponding to the target smart contract bytecode is determined; a second price model corresponding to the historical transaction data is determined; both the first price model and the second price model are mathematical expressions describing the price relationship of a preset trading token pair; the preset trading token pair includes a first token and a second token; Determine the comprehensive price model based on the first price model and the second price model; Based on the comprehensive price model, the probability that the flash loan transaction is a flash loan attack is estimated, and the target flash loan attack probability is obtained; When the probability of a target flash loan attack exceeds a preset attack probability threshold, the flash loan transaction is determined to be a flash loan attack, and a corresponding target alarm operation is executed.

2. The method as described in claim 1, characterized in that, The method for identifying the target AMM nodes among the n account addresses that pose a risk of flash loan attacks includes: Obtain the historical transaction characteristics of each of the n account addresses to obtain n historical transaction characteristics; Based on the n historical transaction characteristics, the flash loan nodes and AMM nodes in the n account addresses are determined, resulting in i flash loan nodes and j AMM nodes; i and j are both natural numbers less than or equal to n, and the sum of i and j is less than or equal to n; The first event token flow graph is transformed into a directed acyclic graph to obtain the second event token flow graph; Initialize the first dictionary; the key in the first dictionary is the node ID in the second event token flow graph, and the value represents the set of nodes upstream of the node that control the flow of its tokens to the current node; during initialization, the value corresponding to the entry node of the second event token flow graph is initialized to a set of nodes containing only its own node ID, and the value of the other nodes is set to the initial set V; the initial set V stores the node IDs of all nodes in the second event token flow graph; The target AMM node is obtained by identifying nodes in the second event token flow graph based on the first dictionary.

3. The method as described in claim 2, characterized in that, The step of identifying the target AMM node by analyzing the second event token flow graph based on the first dictionary includes: The nodes in the second event token flow graph are traversed using a preset traversal method. For each node traversed, a preset risk identification operation is performed to obtain the target AMM node. The target AMM node includes at least one node. The preset risk identification operation specifically includes: Get the first node v currently being traversed; get the first predecessor node set W corresponding to the first node v in the second event token flow graph; initialize the first set R as an empty set, and the first set R is used to store the node set; Based on the first set R, a preset dictionary update operation is performed on the first predecessor node set W to update the first dictionary and obtain the target dictionary; Extract the value corresponding to each of the j AMM nodes from the target dictionary to obtain j values; Determine the value containing the flash loan node among the j values ​​to obtain m values; m is a natural number less than or equal to j. The nodes corresponding to the m values ​​are determined to be nodes in the target AMM node.

4. The method as described in claim 3, characterized in that, The preset dictionary update operation includes: Nodes are retrieved from the first set of predecessor nodes W in a preset order. For each node retrieved, a first dictionary update operation is performed on it to obtain a second dictionary. Check whether the second dictionary is consistent with the first dictionary; If they are inconsistent, then obtain the next node of the first node v and perform the preset dictionary update operation on the next node; If they match, the target dictionary is determined based on the second dictionary, and the preset dictionary update operation is stopped. The first dictionary update operation includes: Obtain the first node ID corresponding to the first predecessor node w; the first predecessor node w is the node taken from the first predecessor node set W at the current time; Extract the value corresponding to the first node ID from the first dictionary, and denote it as the first set DV; When the first set R is empty, R = DV; When the first set R is not empty, R = R∩DV; Add the first node v to the first set R to obtain the target set; Update the value of the first node v in the first dictionary with the target set.

5. The method according to any one of claims 1-4, characterized in that, The step of determining the first price model corresponding to the target smart contract bytecode includes: The target smart contract bytecode is decompiled to obtain the target control flow graph; Obtain the external function name and exchange parameters for the token exchange from the target ABI file corresponding to the target smart contract bytecode; The target function signature is obtained by calculating the function signature based on the preset hash function, the external function name, and the exchange parameters; The entry node in the target control flow graph is determined based on the objective function signature; Starting from the entry node, traverse the target control flow graph to obtain the traversed control flow subgraph; The first price model is derived by inversely based on the control flow subgraph.

6. The method as described in claim 5, characterized in that, The step of inverting the first price model based on the control flow subgraph includes: Initialize the initial variable model VTable-init; the initial variable model VTable-init is a table used to store tuples (var, val), where var is the unique identifier of the variable and val is the possible value of the variable; Initialize stack S to be empty, and then push the first element (VTable-init, entry) onto stack S; where entry is the node address of the entry node; Perform the preset variable propagation tree construction operation to obtain the target variable propagation tree; Starting from the leaf node of the target variable propagation tree, the parent node is expressed by using the child node, and the process is iterated until the root node y of the target variable propagation tree is reached. The variable y corresponding to the root node y is expanded into the expression of the leaf node in the target variable propagation tree to obtain the target expression. The first price model is obtained by replacing the variables in the target output amount_out based on the target expression.

7. The method as described in claim 6, characterized in that, The preset variable propagation tree construction operation includes: S11. Determine whether the stack S is empty. If it is empty, stop the execution of the preset variable propagation tree construction operation and use the newly generated variable propagation tree as the target variable propagation tree. If it is not empty, proceed to step S12. S12. Take the top element from the stack S to obtain the target element (VTable, node). Determine the target node based on the node address node. Update the variable model VTable based on the content in the target node to obtain the updated variable model VTable-new. VTable represents the variable model before entering the target node. S13. Determine the node containing the LOG instruction in the control flow subgraph to obtain the first control flow graph node, obtain the LOG parameter data of the LOG instruction in the first control flow graph node, and identify the target output amount_out from the LOG parameter data; S14. Determine the variable y corresponding to the target output amount_out in the control flow subgraph; S15. Construct a variable propagation tree with the variable y as the root node based on the variable model stored in the stack S to obtain the first variable propagation tree; S16. Push the second element (VTable-new, node-next) onto the stack S, and jump to step S11; where node-next is the node address of the successor node of node.

8. The method as described in claim 7, characterized in that, The step of updating the variable model VTable based on the content in the target node to obtain the updated variable model VTable-new includes: Obtain the target statement type of the target node; the target statement type includes one of the following: declaration statement, assignment statement; Determine the target variable model update operation corresponding to the target statement type; The variable model VTable is updated according to the target variable model update operation to obtain the updated variable model VTable-new.

9. The method as described in claim 7, characterized in that, The step of constructing a variable propagation tree with variable y as the root node based on the variable model stored in the stack S to obtain the first variable propagation tree includes: Obtain the target variable model corresponding to the stack S; The binary tuple set TreeE is initialized to an empty set; the binary tuple set TreeE is used to store variable trees; The variable stack VarS is initialized to be empty. Then, the variable y is pushed onto the variable stack VarS. The variable stack VarS is used to store variables to be processed. S21. Take variable v' from the variable stack VarS and read the val value of var=v' from the target variable model; S22. If val is a constant value, then the first set of elements (v', val) is added to the set of binary pairs TreeE, which means that there is an edge from v' to val in the variable propagation tree. S23. If the value of val is a function expression, then the function expression is scanned from left to right, and the variable v_e and constant c contained therein are collected. The second group of elements (v', v_e) and the third group of elements (v', c) are added to the binary set TreeE in sequence, and the variable v_e is pushed onto the variable stack VarS. S23. Determine whether the variable stack VarS is empty. If it is empty, determine the first variable propagation tree based on the set of tuples TreeE. If it is not empty, proceed to step S21.

10. A computer-readable storage medium, characterized in that, A computer program for storing electronic data interchange is provided, wherein the computer program causes a computer to perform the method as described in any one of claims 1-9.

Images