Evaluation method for risk propagation after decentralized financial attack

Abstract

The invention discloses an assessment method for risk propagation after a decentralized financial attack, and the method comprises the steps: positioning a vulnerability contract involved in the attack at a code level, determining the vulnerability logic of the vulnerability contract, generating a vulnerability detector, carrying out the mode matching of an intermediate representation form of a similar contract, and obtaining a potential victim contract; in a financial level, a contract generating asset loss in an attack and a lost asset type thereof are positioned, and a corresponding historical transaction identification asset provider is tracked and snapshots are carried out; functions related to the loss asset condition in the contract are identified, historical calls of the functions are tracked, and asset dependers related to the loss asset condition are identified; the method comprises the following steps: positioning decentralized applications affected in attacks, identifying issued tokens, tracking holders of the tokens and price mechanisms thereof, and determining decentralized applications related to price changes of the tokens. According to the method, the contract and the decentralized application which are possibly influenced by the attack are effectively identified and evaluated, and the problem of risk propagation detection caused by the attack is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of decentralized finance security, and in particular to an evaluation method for risk propagation after a decentralized finance attack. Background Art

[0002] The rapid development of decentralized finance has been constantly reshaping the financial landscape. As of December 2024, the total locked value on decentralized finance platforms has reached $165 billion. However, the security of the decentralized ecosystem remains a major challenge. From January 2023 to July 2024, the losses caused by decentralized attacks have exceeded $1.6 billion.

[0003] In response, the academic and industrial communities have proposed various security measures, covering all aspects of different life cycles of decentralized protocols. In the stage before the protocol goes live, there are security services and measures such as code auditing, formal verification, and contract vulnerability detection to help identify vulnerabilities and defects in the protocol. In the stage after the protocol goes live, methods such as attack detection and runtime monitoring can be used to detect attacks and identify abnormal states of the protocol. In the stage when an attack occurs, by taking security measures such as attack interception, automatic response, vulnerability analysis, fund flow tracking, and asset rescue, losses can be mitigated and recovered.

[0004] However, although a large amount of work focuses on the three main stages of decentralized finance security, the stage after an attack occurs, especially the cascading impact of an attack on other decentralized applications, still has not received sufficient research, even though the impacts caused by these risk propagations often lead to huge asset losses.

[0005] These cascading risks mainly stem from vulnerabilities at the code level and the financial level. For example, in the Curve attack case that occurred in July 2023, significant impacts were generated at both the code level and the financial level. At the code level, seven contracts (including the Ellipsis project on the Binance Smart Chain) had the same vulnerability as the attacked contract, resulting in similar subsequent attacks. These attacks caused a total loss of more than $49 million. At the financial level, the series of attacks led to an imbalance in the Curve.fi: CRV-ETH trading pool, causing the ConvexStrategy contract, which relies on the asset status in this trading pool to calculate interest, to suffer an improper asset loss of $5,500. In addition, the risk propagation of these attacks caused a total loss of $70 million to various decentralized applications, including Alchemix, JPEG'd, and Metromem DAO. Moreover, these attacks also triggered a large-scale sell-off of CRV tokens, resulting in a significant drop in the price of CRV and triggering a large number of liquidations on lending platforms such as AAVE. Summary of the Invention

[0006] In view of the deficiencies of the prior art, the present invention proposes an evaluation method for risk propagation after a decentralized finance attack, solves the problem of detecting risk propagation caused by the attack, and improves the comprehensiveness and accuracy of risk identification and response.

[0007] The specific technical solution is as follows: An evaluation method for risk propagation after a decentralized finance attack, including independent code level and financial level; identifying potential victim contracts at the code level, and identifying asset providers, asset dependents, and decentralized applications affected by asset losers at the financial level; At the code level, locate the vulnerable contracts involved in the attack and determine their vulnerability logic, and generate a vulnerability detector accordingly; use a similarity detection algorithm to obtain similar contracts similar to the vulnerable contracts; use the vulnerability detector to perform pattern matching on the intermediate representation forms of the similar contracts to obtain potential victim contracts; At the financial level, locate the contracts that incur asset losses in the attack and the types of assets they lose, identify the asset providers before the attack corresponding to them by tracing the corresponding historical transactions, and take snapshots of them. Then, according to the flow of assets, identify the truly damaged asset providers; identify the functions related to the loss of asset status in the contracts that incur asset losses, trace the historical calls of these functions, and identify the asset dependents related to the loss of asset status; Locate the decentralized applications affected in the attack, i.e., victim applications; identify the tokens issued by the victim applications, and determine the decentralized applications related to the price changes of the tokens by tracing the holders of these tokens and their price mechanisms.

[0008] Further, at the code level, generating the vulnerability detector is specifically implemented through the following steps: (1) Locate the vulnerable contracts involved in the attack and determine their vulnerability logic, and convert the vulnerable contracts into intermediate representation forms; (2) Adopt a static analysis method to traverse the control paths of the contracts, derive the execution branches that meet the vulnerability trigger conditions, and use the derivation result as the static analysis result; Or adopt dynamic analysis techniques, through automated input, obtain the runtime abnormal behaviors triggered by specific inputs, and use the abnormal behaviors as the dynamic analysis results; (3) Combine the vulnerability logic with the vulnerability characteristics of the static analysis results or dynamic analysis results to construct a vulnerability detector that can identify this type of vulnerability.

[0009] Further, the intermediate representation forms include: abstract syntax tree, Yul intermediate language.

[0010] Further, at the code level, a similarity detection algorithm is used to obtain similar contracts similar to the vulnerable contract, which is specifically implemented through the following steps: (1) Determine the decentralized application to which the vulnerable contract belongs, and collect the cloned applications of the decentralized application; (2) Use the cloned application as an address label, and collect the corresponding contract addresses and source codes; (3) Use the similarity detection algorithm to perform similarity detection on the contract source codes corresponding to the collected contract addresses, and identify similar contracts similar to the vulnerable contract.

[0011] Further, at the financial level, the asset providers before the attack are identified by tracing historical transactions and snapshots are taken of them, including the following situations: ① When the asset loser issues voucher tokens to its asset provider, generate an asset provider snapshot by tracing the historical transfer transactions of these voucher tokens; ② When the asset loser does not issue voucher tokens and receives assets by calling a fixed function, trace the historical calls of the fixed function to generate an asset provider snapshot; ③ When the asset loser neither issues voucher tokens nor relies on a fixed function to receive assets, trace the historical transfer transactions of the asset loser and screen out the historical transfer transactions corresponding to the required loss asset types from them to generate an asset provider snapshot corresponding to the historical transfer transactions.

[0012] Further, at the financial level, the functions related to the loss asset situation include the functions related to the asset situation provided by the asset loser and the functions of the token balances related to the loss assets; According to the asset dependence form, determine the corresponding asset dependents, specifically including the following situations: ① The asset dependent directly depends on the functions related to the loss asset situation provided by the asset loser. In this case, use financial keywords for fuzzy matching to identify the functions related to the loss asset situation, and trace the historical calls of these functions to discover the asset dependents; ② The asset dependent indirectly depends on the asset situation of the asset loser by depending on the functions of the token balances related to the loss assets. In this case, trace the token balance functions of the loss assets, filter out the historical calls related to the asset loser, and discover the asset dependents.

[0013] Further, the financial keywords include: price, quantity, balance, value.

[0014] Further, at the financial level, decentralized applications related to the price change of the tokens issued by the victim application are determined through two layers of market hierarchies, specifically as follows: The first layer is used to identify decentralized applications that can directly cause fluctuations in token prices, and the decentralized applications include decentralized exchanges and centralized exchanges; For decentralized exchanges, trace the historical transfer transactions of the tokens issued by the victim application, create snapshots for token holders, match the names of the token holders with transaction keywords, and screen out the token holders that can cause fluctuations in token prices, which are the decentralized exchanges that can directly cause fluctuations in token prices; For centralized exchanges, collect all existing centralized exchanges, and identify whether there are trading pairs of tokens issued by the victim application and the price changes of the tokens through the publicly available call interfaces provided by them. If so, it is a centralized exchange that can directly cause fluctuations in token prices; The second layer is used to identify decentralized applications directly affected by changes in token prices.

[0015] Furthermore, the second layer identifies decentralized applications directly affected by changes in token prices, including the following methods: (1) Trace the historical transfer transactions of the issued tokens, create snapshots for token holders; by matching the names of these token holders with behavior keywords, screen out the holders affected by token prices, that is, decentralized applications; (2) Collect floating price oracles, and screen out the oracles that provide the prices of the issued tokens; track the relevant calls for querying the prices of the issued tokens in these oracles to identify the decentralized applications that use and rely on this token price information; (3) Combine the relevant information of the issued tokens and the keywords of the relevant decentralized applications, and conduct an associated search on the Internet to collect and screen out the decentralized applications that may be affected by changes in token prices.

[0016] Furthermore, the behavior keywords in (1) include: voting, liquidation, transfer; the keywords of the decentralized applications in (3) include: voting, borrowing.

[0017] The beneficial effects of the present invention are: The method of the present invention can effectively identify and evaluate the contracts and decentralized applications affected by attacks through multi-dimensional analysis at the code level and financial level, solves the problem of detecting the risk propagation caused by attacks, and significantly improves the comprehensiveness and accuracy of risk identification and response. Description of the Drawings

[0018] Figure 1 is a flowchart of the method for evaluating risk propagation after a decentralized finance attack in an embodiment of the present invention.

[0019] Figure 2It is a schematic flowchart for identifying potential victim contracts at the code level in the embodiments of the present invention. Detailed implementation manners

[0020] The present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments. The objectives and effects of the present invention will become more apparent. The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0021] An evaluation method for risk propagation after a decentralized finance attack, based on two risk propagation paths at the code level and the financial level, identifies and evaluates contracts and decentralized applications that may be affected by decentralized finance cascading effects. The risk propagation identification processes at the two levels are independent of each other. The identification and evaluation processes at the two levels are specifically as follows: As Figure 1 shown, at the code level, first identify the vulnerable contracts involved in the attack, so as to identify potential victim contracts. A vulnerable contract refers to a contract with vulnerabilities exploited by attackers, and these vulnerabilities will become the root cause of the attack. If a certain contract has the same vulnerability as the attacked contract, it may be threatened by a similar attack. As Figure 2 shown, these potential victim contracts are specifically identified through two stages: a similar contract identification stage and a vulnerability logic matching stage.

[0022] In the similar contract identification stage, the following operations are performed in sequence: (1) Determine the decentralized application to which the vulnerable contract belongs, and then use the decentralized finance data tracking platform (DeFiLlama) to collect the cloned applications of this decentralized application; (2) Use the collected cloned applications as address tags and use the Ethereum browser (Etherscan) to collect the corresponding contract addresses and source codes; (3) Use a similarity detection algorithm to perform similarity detection on the contract source codes corresponding to these collected contract addresses, and identify the contracts similar to the vulnerable contract, which are called similar contracts.

[0023] In the vulnerability logic matching phase, the following operations are performed in sequence: (1) Determine the vulnerability logic of the vulnerable contract, that is, clarify the triggering logic and key semantic features of the target vulnerability, such as function call order, state variable dependency relationships, or external call behaviors, etc. Then transform the vulnerable contract into an intermediate representation form (such as an abstract syntax tree, Yul intermediate language, etc.); (2) Select static analysis or dynamic analysis for it according to the specific vulnerability logic. For example, for reentrancy vulnerabilities and access control vulnerabilities, static analysis is selected, while for scenarios that trigger vulnerabilities such as external calls and specific input data, dynamic analysis is selected. Use static analysis methods (such as symbolic execution, etc.) to traverse the control paths of the contract, derive the execution branches that meet the vulnerability triggering conditions, and use the derivation result as the static analysis result; or use dynamic analysis techniques (such as fuzz testing, etc.) to obtain the runtime abnormal behaviors triggered by specific inputs through a large number of automated inputs, and use the abnormal behavior as the dynamic analysis result; (3) Combine the vulnerability features of the vulnerability logic and the static analysis or dynamic analysis results to construct a vulnerability detector that can identify this type of vulnerability.

[0024] The similar contract identification phase and the vulnerability logic matching phase can be carried out simultaneously. Use the vulnerability detector obtained in the vulnerability logic matching phase to perform pattern matching on the intermediate representation forms of the similar contracts obtained in the similar contract identification phase, and finally identify the potential victim contracts that contain the same vulnerability.

[0025] At the financial level, although an attack will inevitably cause losses to the contract, the lost assets do not necessarily come from the attacked contract. Usually, the assets are transferred or authorized by other users or applications as asset providers. These assets support specific functions (such as staking), and in fact, the directly affected asset providers are the direct victims of the attack. To obtain the directly affected asset providers (i.e., the original providers of a certain type of asset), first identify the contract that incurs asset losses in the attack, the damaged assets involved and their types, and then snapshot the asset providers before the attack through the following three methods: ① When the asset loser issues voucher tokens to its asset provider, generate an asset provider snapshot by tracing the historical transfer transactions of these voucher tokens.

[0026] ② When the asset loser does not issue voucher tokens but receives assets by calling a fixed function, generate an asset provider snapshot by tracing the historical calls of this asset receiving function.

[0027] ③ When the asset loser neither issues voucher tokens nor relies on a fixed function to receive assets, trace the historical transfer transactions of the asset loser and screen out the historical transfer transactions corresponding to the required lost asset types among them to generate an asset provider snapshot corresponding to the historical transfer transactions.

[0028] Next, according to the liquidity of the assets, identify the truly damaged asset providers. The truly damaged asset providers refer to the initial providers of a certain type of assets.

[0029] In addition, the asset losses caused by the attack usually have a significant impact on the asset status of the asset losers. For example, the assets are exhausted or seriously imbalanced. The asset-dependent contracts that rely on the asset status to perform specific functions may suffer losses as a result. After determining the asset losers and the types of assets they have lost, judge their corresponding asset dependence forms (direct dependence or indirect dependence) to determine the asset dependents: ① Direct dependence: The asset dependents directly depend on the functions related to the status of the lost assets provided by the asset losers. First, use financial keywords for fuzzy matching to identify the functions related to the status of the lost assets, and then discover the asset dependents by tracing the historical calls of these functions; the financial keywords include: "price", "amount", "balance", "value", etc.

[0030] ② Indirect dependence: The asset dependents indirectly depend on the asset status of the asset losers by relying on the functions related to the token balances of the lost assets. Discover the asset dependents by tracing the token balance function "balanceOf" of the lost assets and filtering to obtain the historical calls related to the asset losers.

[0031] In addition, if the decentralized application affected in the attack issues tokens, the attack usually triggers the market activities of these tokens. According to the principle of risk propagation in the economic market, this risk will successively affect different levels of decentralized applications. Locate the decentralized application affected in the attack, that is, the victim application; identify the tokens issued by the victim application, and based on market behavior analysis, determine the decentralized applications related to the price changes of these tokens by tracing the holders of these tokens and their price mechanisms, and evaluate the risk propagation they have suffered. In the embodiments of the present invention, the impact of risk propagation suffered by decentralized applications is identified and evaluated through two layers of market hierarchies.

[0032] The first layer is used to identify decentralized applications (including decentralized exchanges and centralized exchanges) that can directly cause fluctuations in token prices (such as token sell-offs caused by attacks may lead to price drops, etc.). For decentralized exchanges, first track the historical transfer transactions of the tokens issued by the victim application to create a snapshot of the token holders; then, by matching the names of these token holders with transaction keywords such as "exchange" and "swap", screen out those token holders who can cause fluctuations in token prices, that is, the decentralized exchanges that can directly cause fluctuations in token prices. For centralized exchanges, first collect all existing centralized exchanges, and then identify whether there are trading pairs of tokens issued by the victim application and the price changes of the tokens through the publicly available call interfaces provided by them. If so, it is a centralized exchange that can directly cause fluctuations in token prices, and the token price will drop due to user sell-offs after an attack.

[0033] The second layer is used to identify decentralized applications that are directly affected by token price changes (such as a decrease in token price may lead to a reduction in the cost of secondary attacks, trigger liquidation, etc.). The following lists three typical methods for identifying decentralized applications: (1) First, track the historical transfer transactions of the issued tokens to create a snapshot of the token holders. Then, by matching the names of these token holders with behavior keywords such as "vote", "liquidate", and "transfer", screen out those holders affected by the token price, that is, decentralized applications, such as decentralized autonomous organizations, lending platforms, cryptocurrencies, etc.

[0034] (2) First, collect liquid price oracles (such as Chainlink, Pyth), and screen out those oracles that provide the prices of the issued tokens. Then, by tracking the relevant calls in these oracles to query the prices of the issued tokens, identify the decentralized applications that use and rely on this token price information.

[0035] (3) Combine relevant information such as the name and symbol of the issued token, as well as keywords related to the relevant decentralized applications (such as "vote", "borrow", etc.), and conduct an associated search on the Internet to collect and screen potential decentralized applications that may be affected by token price changes.

[0036] The present invention can identify market fluctuations caused by attacks in real time and track changes in trading behavior after an attack, helping affected decentralized applications and users take countermeasures to avoid possible market losses. At the same time, it can also be reused for contracts and decentralized applications that have been found to be affected by attack cascades to further discover deeper-level contracts and applications in the risk propagation model to prevent the further spread of such risks.

[0037] Those of ordinary skill in the art can understand that the above are only preferred examples of the invention and are not used to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art can still modify the technical solutions described in the foregoing examples or make equivalent replacements for some of the technical features. Any modifications, equivalent replacements, etc. made within the spirit and principle of the invention shall be included within the protection scope of the invention.

Claims

1. An evaluation method for risk propagation after decentralized finance attacks, characterized in that, It includes an independent code layer and a financial layer; at the code layer, potential victim contracts are identified, and at the financial layer, asset providers, asset dependents, and decentralized applications affected by the asset losers are identified. At the code layer, the vulnerable contracts involved in the attack are located and their vulnerability logic is determined, and based on this, a vulnerability detector is generated; a similarity detection algorithm is used to obtain similar contracts similar to the vulnerable contracts. The intermediate representation form of the similar contracts is subjected to pattern matching using the vulnerability detector to obtain potential victim contracts. At the financial layer, the contracts that incur asset losses in the attack and the types of assets they lose are located, the asset providers before the attack corresponding to them are identified by tracing the corresponding historical transactions, and snapshots are taken of them. Then, according to the flow of assets, the truly damaged asset providers are identified; the functions related to the loss of asset status in the contracts that incur asset losses are identified, and the historical calls of these functions are traced to identify asset dependents related to the loss of asset status. Locate the decentralized applications affected in the attack, that is, victim applications; identify the tokens issued by the victim applications, and by tracing the holders of these tokens and their price mechanisms, determine the decentralized applications related to the price changes of the tokens.

2. The evaluation method for risk propagation after a decentralized finance attack according to claim 1, wherein At the code layer, the generation of the vulnerability detector is specifically implemented through the following steps: (1) Locate the vulnerable contracts involved in the attack and determine their vulnerability logic, and convert the vulnerable contracts into an intermediate representation form. (2) Use a static analysis method to traverse the control paths of the contracts, derive the execution branches that meet the vulnerability trigger conditions, and use the derivation result as the static analysis result. Or use dynamic analysis techniques to obtain the runtime abnormal behaviors triggered by specific inputs through automated inputs, and use the abnormal behaviors as the dynamic analysis results. (3) Combine the vulnerability logic with the vulnerability characteristics of the static analysis results or dynamic analysis results to construct a vulnerability detector that can identify this type of vulnerability.

3. The evaluation method for risk propagation after a decentralized finance attack according to claim 2, wherein The intermediate representation form includes: abstract syntax tree, Yul intermediate language.

4. The risk propagation assessment method for decentralized finance attacks according to claim 1, wherein At the code layer, a similarity detection algorithm is used to obtain similar contracts similar to the vulnerable contracts, which is specifically implemented through the following steps: (1) Determine the decentralized application to which the vulnerable contract belongs, and collect the cloned applications of the decentralized application. (2) Use the cloned applications as address tags to collect the corresponding contract addresses and source codes. (3) Use a similarity detection algorithm to perform similarity detection on the contract source codes corresponding to the collected contract addresses, and identify similar contracts similar to the vulnerable contracts.

5. The evaluation method for risk propagation after a decentralized finance attack according to claim 1, characterized in that, At the financial layer, the asset providers before the attack corresponding to them are identified by tracing historical transactions, and snapshots are taken of them, including the following situations: ① When the asset loser issues voucher tokens to its asset provider, generate an asset provider snapshot by tracing the historical transfer transactions of these voucher tokens. ② When the asset loser does not issue voucher tokens and receives assets by calling a fixed function, trace the historical calls of the fixed function to generate an asset provider snapshot. ③When the asset loser neither issues voucher tokens nor relies on a fixed function to receive assets, track the historical transfer transactions of the asset loser, and screen out the historical transfer transactions corresponding to the required loss asset types from them to generate a snapshot of the asset providers corresponding to the historical transfer transactions.

6. The risk propagation assessment method for decentralized finance attacks according to claim 1, characterized in that, At the financial level, the functions related to the loss asset situation include the functions related to the asset situation provided by the asset loser and the functions of the token balances related to the loss assets; Determine the corresponding asset dependents according to the asset dependence form, specifically including the following situations: ①The asset dependent directly depends on the functions related to the loss asset situation provided by the asset loser. In this case, use financial keywords for fuzzy matching to identify the functions related to the loss asset situation, and track the historical calls of these functions to discover the asset dependents; ②The asset dependent indirectly depends on the asset situation of the asset loser by relying on the functions of the token balances related to the loss assets. In this case, track the token balance functions of the loss assets, filter out the historical calls related to the asset loser to discover the asset dependents.

7. The risk propagation assessment method for decentralized finance after an attack according to claim 6, wherein The financial keywords include: price, quantity, balance, value.

8. The risk propagation assessment method for decentralized finance attacks according to claim 1, wherein At the financial level, determine the decentralized applications related to the price change of the tokens issued by the victim application through two-layer market hierarchies, specifically as follows: The first layer is used to identify the decentralized applications that can directly cause token price fluctuations. The decentralized applications include decentralized exchanges and centralized exchanges; For decentralized exchanges, track the historical transfer transactions of the tokens issued by the victim application, create snapshots for the token holders, match the names of the token holders with the transaction keywords, and screen out the token holders that can cause token price fluctuations, which are the decentralized exchanges that can directly cause token price fluctuations; For centralized exchanges, collect all existing centralized exchanges, and identify whether there are trading pairs of the tokens issued by the victim application and the price changes of the tokens through the public call interfaces provided by them. If so, it is a centralized exchange that can directly cause token price fluctuations; The second layer is used to identify the decentralized applications directly affected by the token price changes.

9. The risk propagation assessment method for decentralized finance attacks according to claim 8, wherein The second layer identifies the decentralized applications directly affected by the token price changes, including the following methods: (1) Track the historical transfer transactions of the issued tokens, create snapshots for the token holders; screen out the holders affected by the token price by matching the names of these token holders with the behavior keywords, that is, the decentralized applications; (2) Collect the floating price oracles and screen out the oracles that provide the prices of the issued tokens; track the relevant calls for querying the prices of the issued tokens in these oracles to identify the decentralized applications that use and rely on this token price information; (3) Combine the relevant information of the issued tokens and the keywords of the relevant decentralized applications for associated search on the Internet to collect and screen out the decentralized applications that may be affected by the token price changes.

10. The risk propagation assessment method for decentralized finance attacks according to claim 9, characterized in that, The behavioral keywords in (1) include: voting, liquidation, transfer; the keywords of the decentralized application in (3) include: voting, borrowing.

Images