A Survey of DeFi Security: Challenges and Opportunities

DeFi, or Decentralized Finance, is based on a distributed ledger called blockchain technology. Using blockchain, DeFi may customize the execution of predetermined operations between parties. The DeFi system use blockchain technology to execute user transactions, such as lending and exchanging. The total value locked in DeFi decreased from \$200 billion in April 2022 to \$80 billion in July 2022, indicating that security in this area remained problematic. In this paper, we address the deficiency in DeFi security studies. To our best knowledge, our paper is the first to make a systematic analysis of DeFi security. First, we summarize the DeFi-related vulnerabilities in each blockchain layer. Additionally, application-level vulnerabilities are also analyzed. Then we classify and analyze real-world DeFi attacks based on the principles that correlate to the vulnerabilities. In addition, we collect optimization strategies from the data, network, consensus, smart contract, and application layers. And then, we describe the weaknesses and technical approaches they address. On the basis of this comprehensive analysis, we summarize several challenges and possible future directions in DeFi to offer ideas for further research.


I. INTRODUCTION
W ITH the booming of Ethereum, smart contracts have greatly expanded the application of blockchain within various fields. Due to blockchain cryptocurrency properties, the field of finance has also gained some advantages. Decentralized finance can include stablecoins, decentralized exchanges, cryptocurrency markets, and insurances. And it has locked $200 billion until April 2022 [1]. However, in May 2022, the value locked up in the whole DeFi dropped by a half, which caused us to ponder on the security of DeFi.
While there are some studies about the risk of DeFi, they pay more attention to financial issues. Werner et al. [2] classified attacks according to risk categories from an economic perspective. Qin et al. [3] systematically and quantitatively compared various lending systems and measure the risks that participants may encounter. Gudgeon et al. [4] described the design flaws in lending protocols and DeFi losses due to price volatility. Qin et al. [5] systematically compared CeFi (Centralized Finance) and DeFi, including legal, economic, and market. Bartoletti et al. [6] formalized DeFi theory, which is used to systematically understand and analyze the incentives in DeFi to balance interest rates and prices. Other research proposed by Jensen et al. [7] and Amler et al. [8] are used to analyze the risk of assets in DeFi on Ethereum.
In addition to the research of financial risks in DeFi, optimization schemes are also widely studied. Liu et al. [9] used a mathematical-statistical approach to the market for four types of assets and to clearing to construct MovER, a framework for controlling the risk of the system. Wang et al. [10] proposed Blockeye, which constructs state dependencies from smart contracts and uses the collected transactions to analyze whether it is subject to a DeFi attack. Bekemeier et al. [11] discussed systemic risk, both at the technical level of the blockchain and the economic level and provided VOLUME XX, 2022 1 arXiv:2206.11821v1 [cs.CR] 23 Jun 2022 experience analysis. Even though there are some optimized solutions to vulnerabilities, attacks keep appearing, such as the Ronin Bridge incident [12]. Therefore, the security of DeFi needs to be enhanced. Furthermore, there is still a lack of systematic analysis of the entire DeFi security. To fill this gap, our work in this paper systematically summarizes the vulnerabilities against DeFi systems, following the analytical path shown in Figure 1. We then analyze real-world attacks and the vulnerabilities they exploited, laying the foundation for further research. Finally, we summarize existing optimizations that have been implemented and provide some areas for improvement and possible future directions.
The main contributions of this paper are as follows: (1) To the best of our knowledge, we conduct the first systematic examination of the security issues of the DeFi ecosystem built on blockchain. (2) We systematically summarize the vulnerabilities of the Ethereum-based DeFi system, investigate real-world attack events related to DeFi and classify them according to their vulnerability principles. (3) We survey the security optimizations in DeFi from the system level and give some suggestions for future research directions in this area.

II. BACKGROUND A. ETHEREUM
Ethereum is a public blockchain system initialized using the Proof-of-Work (PoW) consensus mechanism, in which miners fight for control of blocks using computing power in exchange for incentives [13]. However, it has subsequently shifted to the Proof-of-Stake (PoS) algorithm, which is based on the quantity and age of stakes held [14]. It first uses the Turing-complete programming language Solidity and Vyper, etc to develop smart contracts [15] [16]. Anyone can deploy decentralized applications (dapps) on the Ethereum chain that can communicate with others, and the most popular application in the financial field is DeFi, which provides a wide range of financial services.

1) Layers of Dapp on the Ethereum
Dapps, like traditional software architectures, may be separated into 6 layers [17]: (1) The data layer handles offchain data before passing it on to the network layer. (2) The network layer is peer-to-peer, assuring network node autonomy. (3) The consensus layer guarantees that miners wrap network layer requests into blocks. (4) The incentive and consensus layers are interrelated, and the incentive layer ensures that miners do not behave maliciously. (5) The smart contract layer connects the consensus with application layers and exchanges data between them, and (6) the application layer binds the information from the smart contract layer and shows it to the user after processing.

2) Transaction Process on the Ethereum
When a user interacts with the applications and begins a transaction request using the interfaces provided by the smart contract, then the transaction request broadcasts to all nodes on the P2P network chain. When the miner gets the request, it selects and packages the transaction into blocks. The miner adds blocks to the chain using the consensus algorithm and synchronizes them with all nodes on the network. Simultaneously, the smart contract changes the state variables depending on transaction data and visualizes them in the application.

3) Geth
Geth (Go-Ethereum) is an official Ethereum client implemented in the go programming language [18]. It includes instructions for several tasks, such as creating an Ethereum private chain and interacting with the network environment.

4) Gas
To avoid the overuse of network resources, all transactions on Ethereum are paid a cost called gas, and the transaction fee equals the amounts of gas multiplied by gasPrice [19] [20]. The user who proposes transactions sets the gasPrice, and miners with high computing resources would conduct the transaction earlier if the gasPrice is high. There is also a concept called gaslimit, which is used to limit the maximum amount of gas that can be used for a transaction [21]. It means that the maximum charge for a transaction is gaslimit multiplied by gasPrice.

5) Maximal Extractable Value (MEV)
The Ethereum consensus shift caused several definitions to be updated. Initially, MEV was the miner extractable value, but now the maximum extractable value makes more sense. Miner extractable value refers to the profit miners make by performing a series of operations on the blocks they mine [22]. For example, miners reorder transactions to optimize the initial ordering of transactions and earn additional ordering optimization (OO) fees [23]. And the phenomenon that miners sell priority in blocks to make users keep raising the cost of gas is called Priority Gas Auctions (PGA).
Maximal Extractable Value is the maximum value that the validator V can extract by reordering, inserting, or not executing the transactions T i,...,j = {t i , ..., t j } in the block. In addition, we assume that the balance in V before the transaction is b(s) and b(s ) is after the transaction. So the value obtained by sequential execution EV (V, T i,...,j ) equals b(s ) − b(s), and R(T i,...,j ) means the order of transactions is in full array. Thus the maximal extractable value M EV can be defined as M EV = max(EV (V, R(T i,...,j ))).

B. DEFI 1) Development of DeFi
The introduction of blockchain technology [24] has changed the traditional financial ecosystem. With the advent of Ethereum, smart contracts became the basis for the development and implementation of DeFi. Since the landing of MakerDAO in 2014 which is the first Ethereum-based DeFi project, several DeFi protocols have emerged to implement functions of traditional CeFi, such as lending platforms, exchanges, derivatives, and margin trading systems [25]. As liquidity mining is mentioned in 2020, DeFi is pushed into high gear with the emergence of decentralized exchanges such as Compound, which are entirely managed by smart contracts. Money Legos brings unlimited creativity to DeFi products. It means that a new financial product can be realized by combining the underlying DeFi protocols [26]. In 2022, regulated decentralized finance (rDeFi) becomes the new trend in DeFi development [27].

2) DeFi Service
As seen in Figure 1, DeFi applications can be made up of DeFi services, also known as protocols, such as exchange, lending, and asset operation. Blockchain will wait for assets or data to be processed through protocols before uploading them to the application layer, which is the market [28]. The Decentralized Exchange (DEX) serves as a forum for asset suppliers and buyers to engage, it can separate into two types: centralized order system and automated market maker (AMM) [29]. The former is comparable to a regular exchange in that customers produce trade orders following transactions start. The latter is accomplished quickly by initiating a transaction using a previously constructed asset price algorithm.

3) Market Mechanism
In addition to technological issues, DeFi has an economic mode of operation, which is the market mechanism. Users can control and alter numerous assets using the DeFi service normally. However, attackers can benefit by manipulating the asset through market-based strategies at the economic level.

III. ANALYSIS OF VULNERABILITIES
From the proposal of Ethereum to 2022, various vulnerabilities have emerged to promote the ecological development of decentralized applications (dapps). Therefore, studying the vulnerabilities related to DeFi is useful for understanding the defense methods of attacks. To summarize threats in DeFi, we focus on data, consensus, contract, and application layers.

A. DATA SECURITY VULNERABILITIES
For the data layer, if attackers change the data under the chain during the uploading process to the chain, it will result in irreversible mistakes due to the immutability of the blockchain. And it could encounter oracle mechanism vulnerability and inappropriate key management.

1) ORACLE MECHANISM VULNERABILITY
The oracle is an automated service mechanism that allows the system to obtain the off-chain asset price data as input [2]. And smart contracts rely on the exchange rates of prices provided by oracle for proper operation. However, as Figure 1 shows, the risk to oracle grows drastically when a single point of failure occurs. For example, over 3 million sETH were arbitrated due to the oracle errors in Synthetix, a protocol that converts entity into synthetic [30]. Oracle risks can be divided into technical and social problems.
Technical oracle problems may be defined as a process of passing data, which has three key elements: (1) How to collect all the data accurately? (2) How to process the data with as few errors as possible? And (3) how to upload the processed data to the smart contract?
Furthermore, the current oracle form may be centralized and distributed. Centralized oracle uses trusted third parties to collect, process, and transfer data to smart contracts. Distributed oracle consists of numerous nodes that take data from multi-sources and process it using an algorithm, such as a consensus [31] or weighted voting method [32]. Finally, the oracle system assesses the chain information.
There are not only technical problems but also social problems in oracle [33] [34]. Assuming such a game where there exists an Oracle O i . The O i picks the off-chain data and processes it as D n = (d i , ..., d j ). The contract S i = (f i1 , ..., f im ) uses D n for transactions T x i , where f ii is the i th function in the contract S i . If an attacker a i pays c to modify d i in D n , and obtains benefits b ii . When the cost c by the attacker is less than the benefits b ii , the attacker gets a profit which would be attractive for other attackers. While the c cannot be measured directly from technical methods, it requires analysis of specific social situations, so the oracle problem is controversial in terms of social issues.

2) INAPPROPRIATE KEY MANAGEMENT
In the DeFi ecosystem, wallets are used to manage private keys, and asset authentication is based on keys in most cases. However, similar to Bitcoin, the DeFi system suffers from the problem of improper key management. Existing key management methods, such as physical storage [35] [36], offline wallets [37] [38], and password-derived wallets [39], have some drawbacks. In Table 1, we summarize 9 forms of wallets, where local storage is the initial form of local file storage, hardware wallets, and QR code wallets both belong to physical storage wallets, and the remains belong to smart contract wallets. And TxS is the transaction speed, based on local storage, above which is a , and vice versa is a ×. The same applies to Flex, Sec, Sca, TP, and TxC, which represent transaction speed, flexibility, security, scalability, transparency, and transaction costs, respectively.
In Ethereum, users can access the Ethereum chain by using Geth. When a user creates an account a i , the client generates a file to be stored locally, which contains the unique key key i associated with the account a i . Before the account initiates a transaction T x i or mining, the client reads the key i in the file. However, anyone who does not have restricted access can read the file and even falsify (key i , ..., key j ) for profit.
There are three types of wallets, software, hardware, and paper, depending on the form in which they exist [40]. Hardware and paper-based storage, which are physical storage, are more secure because they store keys in a way that isolates them from multi-user interaction. But it also has the VOLUME XX, 2022 The transaction process requires multiple owners to sign to ensure users' security × ×

Forwarder Wallets
Forwarding assets to a master wallet and users only need to preserve the subkey × ×

Controlled Wallets
The third party keeps the key and anyone who uses the key needs authorization × × × ×

Update Wallets
Users can customize the update by selecting some parts to be updated × ×

Smart Wallets
Wallets with enhanced functionality that achieve expansion of normal functions × × × weaknesses of poor scalability [41] and the inability to have a single point of failure caused by the architecture design [35]. Smart contract wallets are divided into six types in [42]. They restrict direct access to assets and provide some APIs (Application Binary Interfaces) for manipulating data.
• Simple wallet: It is the initial form of wallet, offering simply raw transaction capability and storing all keys in files. When a malicious parity obtains file system permissions, keys can be read or even manipulated. • Multi-signature wallet: It requires the co-signature of many owners for increased protection. The combination of many signatures dilutes the individual's influence, so it also provides decentralization. And the public multiple signature combination could enhance transparency. • Forwarder wallet: It adds forwarding operations to the signing process, such as password-derived wallets which allow users to customize the master key and then derive sub-keys to control the asset. The forwarding operation faces a balance between transparency and security. If the derivation algorithm is publicly available, attackers who got the master key in some ways would reproduce the derivation process to obtain all sub-keys. • Controlled wallet: The custodial wallet is an example of a controlled wallet since it keeps ownership of the account and grants just access to users. It offers some protection by centralized management, but the nontransparent action also tests the credibility of managers. • Update wallet: Update wallets permit users to modify updates depending on features, allowing for greater flexibility in wallet operation. However, compatibility across many versions might result in worse security. • Smart wallet: Smart wallets include some sophisticated features, such as key recovery. As a result, the smart contract enables wallets to execute a range of services in addition to transferring money, but it adds to the dangers involved with smart contracts in III-C.

B. CONSENSUS MECHANISM VULNERABILITIES
Blockchain, such as Ethereum, is consensus-based. Up to now, many significant works have already been done in design, testing, auditing, and maintenance. So there aren't many consensus flaws, but we gather the consensus bugs that occurred in Geth according to [43]- [45] in Table 2. There are four severity categories, with low suggesting that the developer resolved before they occur. The middle level was deployed to the test network before discovered, while the High was in the main chain. The critical one implies that the vulnerability is widely available and has a significant impact on the integrity of the network. Certain malicious behaviors utilize consensus rules to affect the sequences of transactions. There are a variety of attacks combined with MEV, such as flash loans [46] [47], sandwich attacks [29] [22], and forking attacks [23].

1) TRANSACTION ORDER VULNERABILITY
It will be used to describe this phenomenon in which an attacker alters the initial sequence of transactions by leveraging the miner's desire for profit. The sandwich attack is a typical example, the attackers predict that the victim will buy asset A, and pay a higher gas fee to acquire it before the victim at a lower price. And then they sell A at a higher price for arbitrage since the victim's purchase boosts the price [29].

2) FORKING VULNERABILITY
Forking events in DeFi are generally associated with transaction fee-based forks and time-bandit attacks [23]. Mining revenue incentivizes miners to perform honestly, but the OO fee motivates them to reorder transactions in the block, enhancing the income. Most bugs contain forking vulnerabilities in Table 2, for example, memory corruption, incorrect requirements, shallow copy, and certain sequences.

3) STATE MANAGEMENT VULNERABILITY
Transactions in Ethereum are based on updating states between blocks [48]. According to the Ethereum consensus rules, the confirmation between the old and new blocks needs to be completed within 12 minutes. Therefore, if the extraction of the state variables within the block is completed by attackers, then they can attack the transaction within the specified time. For example, timestamp overflow and incorrect requirements are in Table 2. The former is because the timestamp exceeds the representation of uint64, resulting in a hash error in the block [44]. The latter is that the timestamp in a block gets permission mistake, which means the block to be refused by the chain permanently, causing a chain fork and the execution of a double-spending attack [43].

C. SMART CONTRACT VULNERABILITIES
There are 20 types of smart contract vulnerabilities in Ethereum defined in [49], of which Table 3 shows the weaknesses that attackers might use to make a profit. We searched CVE (Common Vulnerabilities & Exposures) and summarized over 500 vulnerabilities [50]. We categorized these bugs written by Solidity into the several types as detailed below:

1) ARITHMETIC OPERATIONS VULNERABILITY
In Solidity, bugs such as integer overflow, float lack of precision, and division by zero are common during arithmetic data operations. An upward overflow can occur if a memory integer exceeds the maximum range, e.g., uint256 is a default type of integer that can express the number from 0 to 2 256 − 1. In Listing 1, the function allows the owner to add tokens to the user, but a sufficient amount on line 3 can make the balance in balance[target] vanish.
Since Solidity lacks the float type of data structure, the phenomenon in which the float result of an operation might lose coins. When one integer is divided by a larger integer, the result is always 0. For example, 1 ETH divided by 10 Eth equals 0. Even some contracts do not restrict the operation of division by zero, which results in code logic errors as the result of the calculation becomes big infinitely.

2) UNMATCHED ERC-20 STANDARD
Ethereum provides various APIs for developers to implement certain functions, such as transferring money, but some developers may not adhere to all standards, resulting in problems in smart contracts. The ERC-20 standard is one of the APIs used to manipulate cryptocurrencies, including how to transfer tokens between addresses and access token data [51]. When transferring tokens, for example, transfer(), transferFrom(), and approve() will return a boolean value to indicate whether the function succeeded, and many smart contracts cause transfer mistakes since they do not verify the return value.

3) TRANSACTION STATE DEPENDENCY
Contracts should check the permissions of certain sensitive invocations that use the global variable tx.origin, which points to the address in the entire call stack where the transaction was originally sent [52]. Assume the Wallet contract sends a transaction to the Attack contract, and then the attack() function invokes the transfer() function in the Wallet contract, at which point tx.origin meets the detection in line 6, making the success of the attack.

4) SUICIDAL AND GREEDY CONTRACTS
Smart contracts usually include a provision enabling the owner to commit suicide if the contract is challenged. The SELFDESTRUCT opcode (operational code) in a suicidal contract can ignore all contract code logic, even the fallback() function [53]. However, attackers utilize this feature to corrupt the logic of some contracts, which leads to restrictions on all other operations that depend on the contracts. For example, the Parity wallet was attacked by a suicidal contract in 2017 [54], which resulted in a permanent lock of all cryptocurrencies that transferred to the wallet before the wallet maintainer fixed the vulnerability. Similar to the suicidal contract, the greedy contract locks up the ether, but it is alive. Greedy contracts do not have instructions related to the withdraw and send [55], such as send, and transfer, so it locks all ethers and cannot withdraw. Therefore, making sure there are means to get ether out before transferring it to a contract [49].

5) REENTRANCY VULNERABILITY
The concept of threads does not exist in Solidity, so it cannot execute more than two operations concurrently. This means that when a contract initiates a call via call(), it must wait for the completion of the call before making the next call. However, it would be attacked if the callee contracts change the global state during the waiting [56]. The DAO attack leverages the recursive invocations to make the system keep cycling until internal assets run out. It exits in line 4 of Listing 3 [57], where the original recipient continues executing call.value() after a successful transfer.

6) UNCHECKED EXTERNAL CALL
The return value or the arguments of an external call can affect the states of the code, and many contracts do not check the return value leads to vulnerabilities. The mode of logic used in this bug is similar to that of misuse ERC-20 standard. When a function calls code logic outside the contract, it is equivalent to the entire runtime in a black box. At this point, failure to check the return value of the external call may cause the logic of the contract to break. For example, when multiple functions are nested, and the external call does not check the return value of the internal call in time can go wrong [49].
Smart contracts in the DeFi trade by using external call functions including delegatecall(), call(), send(). More crucially, a failed external call in these methods results in a transaction not being rolled back, which can cause logical effects.

7) STRICT BALANCE EQUALITY
Equations are commonly used in programs to make decisions concerning contract logic. When an attacker employs some methods, such as a suicide transfer ether, to alter the state of the variables utilized in the equation, rendering the judgments of the equation incorrect, the attack affects the logic of the code that follows the equation. For example, in Listing 4, when the balance in the account is 1 ether and it passes the check in line 2. In line 3, the attacker transfers ether into the account, causing the judgment to fail, so the transfer in line 4 does not follow the normal logic. It is a loophole caused by not fully checking the judgment conditions of the equation.

D. APPLICATION LAYER VULNERABILITIES
The application layer visualizes the state in the chain and interacts directly with the user. In this paper, we focus on dapps in the financial domain. DeFi applications, in general, suffer from price manipulation attacks similar to traditional centralized financial applications. With the current development, the problems in the application layer could be divided into lending market imperfection, cryptocurrency instability, design imperfection, and abusive transaction exposure.

1) LENDING MARKET IMPERFECTION
When the prices in the market are out of balance, it will result in bad debts for one of the participants in the lending market. To get more loans, attackers can boost the cryptocurrency exchange rate on the oracle by modifying the real-time price-related status before the loan is made. For example, an attacker can gain a larger quantity of tokens by directly manipulating token prices in the asset pool or increasing the price of collateral before lending [58], putting the borrower in danger of bad debt.

2) CRYPTOCURRENCY INSTABILITY
The large fluctuations of cryptocurrencies come from many reasons, one of which is the Pump-and-Dump. The instability can easily trigger liquidation procedures. Exchanges have chosen stablecoins, which are tied to the price of real-world money, as the pricing standard to minimize losses, but they still exist as a risk. For example, a 99.98 % plunge in May 2022, in the price of the luna coin whose value is tied to a stablecoin called Terra, left the entire crypto market with over $700 million in collateral liquidated [59].

3) DESIGN IMPERFECTION
The attackers make use of incorrectly configured functionality or specific convenience features of DeFi platform exchanges [60]. Flash loan is designed as risk-free loans to be a convenient improvement to the loan that needs to borrow the flash loan, exchange it for currency, and repay the loan in an atomic transaction. For example, attackers borrow the flash loan to receive collateral at a premium and make a profit in this atomic transaction [61], which results in bad debts for the users who borrow money from attackers.

4) ABUSIVE TRANSACTION EXPOSURE
Exchanges disclose all transactions as soon as feasible to ensure completely behavioral transparency because off-chain matching services are not automated. Unfortunately, exchanges can restrict access to select users and launch denial of service attacks [62] to dominate the market, audit transactions, and even front-run orders.

IV. ANALYSIS OF ATTACK EVENTS
In this section, we investigate real-world attacks in the DeFi ecosystem [63] [64] and analyze the vulnerabilities exploited in the attacks.

A. DATE LAYER VULNERABILITIES 1) Private Key Leakage
Developers deploy DeFi applications on the blockchain through private keys managed in the wallet. Also, users confirm and initiate transactions on the DeFi app through the private key. We summarize real-world DeFi security events due to private key leaks in Table 4. We believe that there are two reasons for these security incidents: (1) poor management of secret keys; (2) phishing attacks.
Poor Management of Secret Keys: In the Meerkat Finance [65] incident, the administrator of the project used a private key and a false time lock in the contract. It transferred about $30 million worth of BNB tokens from the BNB Vault. In Listing 5 [66], the administrator uses the visual ambiguity of the number "0" and the letter "o" to make the variable slot values in the admin() and setAdmin() functions differently. This means that the time lock of BNB Vault is false and the administrator can achieve the transfer of BNB tokens through this backdoor.
Phishing Attack: The scripts embedded in the DeFi website interact with the wallet via API, which may give opportunities for phishing attacks [67]. In the BadgerDAO incident [68], the attackers stole the Badger developer's secret keys and injected malicious scripts into BadgerDAO's web pages. The scripts intercept the user's transactions and prompt the user to allow the attacker to operate on the ERC-20 tokens in their wallets.
The transparent nature of DeFi allowed the attacker to easily gather information about the developers. The attacker sent malicious emails to bZx developers, stealing the management private key of bZx deployed on the BSC and Polygon chains. The attackers used the management private key to upgrade the contract to mint unlimited tokens [69].

2) Oracle Vulnerability
The DeFi ecosystem relies heavily on oracle to provide offchain or on-chain asset data, and cannot verify the accuracy of the data. This means that if the DeFi protocol uses only a single DEX as the source of asset prices, then the DeFi protocol will assume that it is true and accurate regardless of the movement of its asset price data. In Table 4, oracle attacks have caused significant damage to DeFi applications. Most of the Oracle attacks are based on the following steps [70].
1) Preparation of funds. The attacker borrows a large number of assets unsecured through various Flash Loan providers, e.g., bZx, dYdX. He/She intends to inject the assets into other DeFi agreements to inflate their prices while hoarding the target assets. VOLUME XX, 2022 2) Raising the price of the target asset. The attacker manipulates the oracle by balancing the target assets stored in the liquidity pool, i.e., by exchanging a large number of tokens back and forth between different liquidity pools. Since a single oracle is used, it passes the manipulated price data into the DeFi protocol. 3) Profiting. The attacker exchanges the target asset for money borrowed by the flash Loan which is a service provided by DeFi, e.g., collateralized borrowing. As the attacker inflates the price of the target asset, it can exchange the target asset for a larger amount of other assets. By this step, the attacker will gain much profit. 4) Loan repayment. The attacker restores the assets in the liquidity pool to their initial state to avoid losses caused by price slippage [70], and repays the loan.
The bZx attack [71] happens in February 2020, it was through the above attack steps that the attackers made a profit of about $0.9 million. The attacker borrows lots of ETH through the bZx platform. At KyberSwap AMM, a portion of the ETH is exchanged for sUSD tokens to drive up the price of sUSD. Next, the attacker buys the sUSD from the Synthetic Depot contract at the normal price. The attacker pledges the sUSD in the account into the bZx protocol in exchange for ETH. As the price of sUSD in bZx is inflated, it can be exchanged for more ETH. Finally, the attacker repays the loan.
In 2021, Vee Finance lost 35 million USD due to the oracle vulnerability. It had only one oracle as a price input source. At the same time, the attackers profited by using errors in the contract to bypass the slippage protection checks. Similarly, the Harvest protocol uses the USDT price in Curve as the price data. Since the USDT price becomes lower at this point, the attacker can pledge more USDT with the same assets. The attacker performed 32 attacks and profited 24 million USD from the protocol [72].

B. CONSENSUS LAYER VULNERABILITIES 1) Sandwich Attack
Currently, the blockchain is based on the consensus of Proof of Work, which gives bookkeeping rights to the node that calculates the required hash value. Nodes with bookkeeping rights can specify the order of transactions according to their own rules. The dependency on transaction order vulnerability is one of the factors affecting the security of smart contracts, and it also applies to DeFi applications. For example, the sandwich attack is now widely studied.
The Sandwich attack applies to automated market makers like Uniswap and takes advantage of a special feature of AMMs, such as the fact that for every token swap that occurs on an AMM like Uniswap, the price of its swapped tokens changes. The steps of the Sandwich attack are as follows.
1) Network Spy. There are some spy nodes deployed on the network to collect all the transactions for asset exchanges. If attackers consider that a transaction that exchanges token A for token B is profitable, they will create two transactions for racing to control the transaction and make a profit. It means that the price of token B in the liquidity pool will be increased. 2) Transaction creation. The attacker creates a frontrunning transaction to exchange token A for token B, and the price of token B in the liquidity pool will be raised. If the price of token B rises too much, the slippage detection may be triggered and the attack will be failed, so the attacker will generally control the number of tokens purchased. The victim is also exchanging token A for token B, which causes the price of token B to continue to rise. As the attacker's front-running trading causes the price of token B to rise, the victim can only obtain less than the expected amount of token B. Finally, after the victim's transaction, the attackers would create a back-running transaction that converts token B into token A, thus making a profit. According to our research, sandwich attacks often occur on automated market makers, such as Uniswap, Linch, and SushiSwap. About 30,000 Sandwich attacks occurred on Ethereum, which allowed the attackers to generate a profit of 2 million USD [73].

C. CONTRACT LAYER VULNERABILITIES
Smart contracts are the basis for implementing decentralized financial instruments. When DeFi applications were deployed on the blockchain, some errors in the smart contract might cause irreparable damage to DeFi [74].

1) Arithmetic Vulnerability
Almost all DeFi applications involve arithmetic operations on currencies. These operations consist of adding or subtracting from account balances and converting exchange rates between different tokens [2]. There have been overflow and precision loss vulnerabilities in the DeFi ecosystem. These arithmetic vulnerabilities have caused significant damage to DeFi applications.
Overflow: In April 2018, there were multiple DeFi applications, e.g., OKEx, that suffered huge losses and were forced to shut down due to an overflow vulnerability in the ERC-20 token contract, e.g., MESH and UGToken. There is a commonality in this overflow event, which is caused by the transferProxy() function in the contract. The overflow vulnerability appears in line 2 of Listing 6 [75]. Since fee and value are both input parameters, they can be controlled artificially. Then an attacker can design the incoming parameters so that their size exceeds the storage range of uint type and an overflow occurs. When an overflow occurs, it causes the unsigned integer to flip to 0 as a whole. This means that the attacker can bypass the check of the if statement in the second line and make it transfer the tokens to an address with no balance [76].
Underflow: The larger loss in arithmetic vulnerability is Compound Finance. Its reward payouts CompSpeed can be set to 0, which indicates that reward payouts are suspended, and the market award index supplyIndex is 0. For new users, their award index supplierIndex was initialized to CompInitialIndex preset by Compound as 10 36  There was no attacker in this security incident, but rather an overpayment of rewards due to an underflow vulnerability in the contract. This incident caused the Compound 80 million USD in damages. In 2022, Umbrella NetWork also lost 0.7 million USD due to an underflow vulnerability.

2) Reentrancy Vulnerability
A contract executing a transaction invokes a malicious contract account, and the malicious contract account invokes a function in the contract before the contract state changes [80]. The most significant reentrancy attack in Ethereum was the DAO attack [81] that caused a hard fork of Ethereum. Reentrancy attacks were applied to the DeFi protocol with its development. In Table 4, 54 million USD was lost to DeFi due to a reentrancy vulnerability. In April 2020, the dForce protocol suffered a reentrancy attack with a loss of about 24 million USD. The attackers exploited the ERC-777 [82] compliant imBTC tokens. Compared to the ERC-20 token standard, the ERC-777 token standard has one feature. When you send or receive ERC-777 tokens, they go through Hook in the form of a callback to notify the sender or recipient. The attacker in that incident took advantage of this feature and re-entered the dForce contract to increase the amount of imBTC collateral and get a higher yield [2]. shares = _amount;} 10 else{ shares = (_amount.mul(totalSupply() )).div(_pool); } 11 _mint(user, shares); } 12 }

LISTING 9. Snippets of GrimBoostVault Contract
Grim Finance on the Fantom [83] chain lost 30 million USD due to a re-entry vulnerability. First, the attacker creates a contract to inject the cryptocurrency borrowed through the Flash Loan service into Spirit Swap [84] to obtain Spirit-LP certificates. Next, the Spirit-LP certificates were pledged to the GrimBoostVault contract in exchange for the GB-BTC-FTM, which is a token, via the depositFor() function in Listing 9 [85]. Since the legitimacy of the token contract is not verified, the attacker re-calls the depositFor() function in the safeTransferFrom() function of the malicious contract, implementing reentrancy to collateralize more GB-BTC-FTM for profit. Finally, the attacker returns the borrowed funds.

3) Logical Vulnerability
According to our investigation, a large number of vulnerabilities in the DeFi application stem from simple programming errors in the smart contract [2]. Due to the tamper-evident nature of the blockchain, these errors can cause significant damage to the DeFi application.
token copy: This is the third attack on bZx in 2020. The attackers exploited a vulnerability in the contract by passing the same address to the sender parameter balancesFrom and the receiver parameter balancesTo in the bZx contract, thus copying the balance in the account [86].
Low-level calls: Starstream Finance is a DeFi project on the Metis Andromeda network. As seen in Listing 10 [87], the vulnerability is due to the public function execute() of the DistributorTreasury contract using an unchecked external call to.call(), allowing anyone to make an external call. It means that an attacker could use the function to generate a call to the withdrawTokens() function to extract the STAR Token in the StarstreamTreasury contract.

LISTING 10. Snippets of DistributorTreasury Contract
Self-destruction: Self-destruction of contracts and destruction of tokens in contracts are both common operations in the DeFi ecosystem. Usually, attackers will transfer stolen valuable cryptocurrency into the contract under their control. To avoid being traced, the attackers will destroy the attack contract after transferring the tokens in their contracts.
The Eleven Finance attack [88] is caused by the fact that the attacker does not destroy the proof of assets when withdrawing them from the contract, thus enabling the withdrawal of the deposit twice. The specific reason for this attack is that the emergencyBurn() function in the ElevenNeverSellV insurance contract allows the attacker to withdraw the deposited assets without destroying their proofs. Afterward, the attacker calls the withdraw() function in Listing 11 [89] to perform the normal process of withdrawing the assets. This incident caused a loss of approximately 4 million USD to Eleven finance.

D. APPLICATION LAYER VULNERABILITIES 1) Utilization of Flash Loans
Flash loan is a type of unsecured lending that relies on the atomicity of blockchain transactions at the point of execution [46] and adds dynamism to DeFi. Unfortunately, attackers use Flash Loan to reduce the cost of the attack. According to our survey, most DeFi attacks involve Flash Loan services. At the same time, Flash Loan provides asset protection for arbitrageurs to realize price manipulation of traditional finance on DeFi. The arbitrageur uses part of the borrowed assets to raise or lower the price of the assets in the AMM liquidity pool, that is, the asset exchange ratio. The arbitrageurs then use the remaining loan to make another trade for profit [58]. Finally, they repay the loan. The Elephant Money DeFi protocol that occurred in April 2022 was based on a traditional price manipulation attack, which resulted in a loss of 11 million USD. The attackers minted the TRUNK stablecoin, increasing the price of the ELEPHANT token [90]. They finish by making a profit by buying more WBNB and BUSD tokens with ELEPHANT and TRUNK.

V. ANALYSIS OF SECURITY OPTIMIZATION
Even though numerous attacks exploit various vulnerabilities, many research efforts have got success in detecting and defending against these attacks, which fuels the rapid development of blockchain. We analyze the vulnerabilities in the Section III according to the hierarchy shown in Figure 1.

A. DATA SECURITY OPTIMIZATIONS
As the oracle mechanism and key management flaws are mentioned in III-A, optimizing the data layer can effectively prevent attacks from exploiting the flaws to tamper with the authenticity of the data.

1) Oracle Optimization Schemes
Due to the necessity for off-chain asset information such as pricing, there is an expanding demand for superior oracles [100]. There have been decentralized and centralized related studies for this event, as summarized in Table 5, where the 'C' means centralized, 'D' means decentralized, 'On' represents the method is on-chain and 'Off' is off-chain.
Town Crier (TC) [91] employs SGX technology, a trusted execution environment (TEE) offered by Intel, to address the issue of safe communication between blockchain smart contract SC = (SC 1 , SC 2 ) and the network layer. We assume that TC has one extra TCP layer than the HTTPS network protocol for providing dependable data sources. When SC 1 launches a transaction to SC 2 , the program prog created in preparation in TC receives the transaction's datagram request, then obtains the data source through the external network's HTTPS protocol, and finally delivers the request with a digital signature to the requester SC 1 . It separates the hostile network operation and host process.
Uniswap [98] automatically reconciles the required cryptocurrency pricing information by using the Automated Market Maker (AMM), using an on-chain smart contract to set up the symbolic equation. We assume a centralized asset container pool with a large number of two cryptocurrencies a and b, which correspond to stocks of (a) and (b). Uniswap allows (a) × (b) = k, where k is a constant. When a portion of a is borrowed, (b) grows due to the drop of (a).
TLS-N [93] is an extension of transport layer security (TLS). TLS generates a network encrypted channel for data exchange to ensure that the data of the conversation between the two parties are not accessed by the adversary. TLS-N is proposed to solve the requirement of the third trusted party. It starts evidence generation and collection after the traditional handshake, which means that the evidence generator signs the handshake state with the private key immediately after the handshake. And TLS-N records all the handshake operations. All handshake records and proof signatures are utilized to assure non-repudiation of the conversation.
Provable [99] is similar to Chainlink [92] in that it sends currency information to Ether via operational nodes. The distinction is that the former uses trusted computing to ensure the accuracy of information across the network and transport layers, while the latter operates outside the chain. The latter uses median value computations to store multiparty data in the decentralized oracle network, ensuring safe data exchange. And it is worth noting that Chainlink uses a reputation system to stimulate each node.
Astraea [94] provides a voting oracle approach using the game analysis. It selects the submitters of the funding allocation scheme, the voters who vote on the funding, and the validators who verify the correctness of the scheme. The advantage of this strategy is that it ensures the accuracy but not the legitimacy of the data for reasonable participants.
Meter [95] is a sidechain built in parallel to the blockchain using PoW consensus, which increases the throughput and scalability of the main chain. The cryptocurrency MTR on Meter is an autonomous and distributed coin passed to other blockchains, such as Ethereum, through sidechain technology, making the price of the cryptocurrency stable. It im-VOLUME XX, 2022 proves not only the performance but also expansion. MakerDAO [96] takes various asset prices from multiple oracle sources, then the committee votes to select one set of trusted feeds and pass them to the smart contract. However, to prevent the attacked information from being uploaded to the chain, the oracle security mechanism delays the input of the prices for one hour after being obtained. Finally, the committee voted to set up an emergency oracle to freeze a malicious oracle to prevent the oracle crash.
DECO [97] is similar to TLS-N, they are both interested in evidence generation. However, TLS-N needs advanced modifications to the server protocol to generate a proof, whereas DECO generates a proof in this section using the zero-knowledge proof, which means there is not a revelation of encryption keys. P and V are given a shared key by the prover P , the verifier V , and the TLS server S. P initiates a query request using the shared key, S responds and transmits data to P . V detects the request, respond, and then announces its shared key. Finally, P proves the returned data.
ProMutator [70] detects whether an oracle is vulnerable by analyzing normal and abnormal transactions against the price oracle. It uses modified EVM to run the transaction data of price oracle attacks according to predefined rules. And then the comparison of the original and mutating traces generates reports, which has analyzed the differences.

2) Wallet Optimization Schemes
Users initiate a transaction and sign it using the key pair, the assets in the account are lost when the key leaks to an adversary. Some studies [35] [37] [101]- [106] proposed specific solutions for wallet management and wallet architecture.

Reference
Key Scheme [35] Improving collaborative key generation and signature [37] Combination with a cold and hot wallet for privacy [101] A practical way to public key encryption [102] A p2p wallet scheme with a routing protocol [103] A lightweight wallet based on TEE [104] A new scheme for creating sub-wallet keys [105] The shared key generated by T-ECDSA for signing [106] Combine signatures into one based on bloom filter According to [35], existing hardware wallets migrated from the PC wallet architecture, resulting in a bad design that does not fundamentally fix the problem when just utilizing authentication and communication encryption. Interactive authentication adds several signatures and keys to the original wallet structure, which prevents attackers from manipulating the keys for transactions using a malfunctioning wallet.
Combined with software and hardware, two android applications created in [37] provide privacy protection. It contains a cold wallet with key storage in the form of QR codes and a hot wallet for sending transactions, respectively.
S. He et al. [101] presented a new practical way of public key cryptography deployment. It formalizes the user's interactions with the management server m, the central server c, and the proxy p. This method provides five protocols, the first of which initializes all parameters in preparation for secure channels and verification operations, such as producing keys and verifying digital signatures. The second process is registration, in which u is bound to the m and produces valid login credentials. The registration data is then sent to c. The third is a backup, and the fourth is a verification that is utilized to perform a transaction in p. The final service provided by it is wallet recovery with the help of registration and backup.
X. He et al. [102] used a routing protocol to convert the C/S architecture into a peer-to-peer (P2P) structured wallet management scheme. It solves the multi-constraint disorder problem and distributes the data through a P2P network. In addition, it proposes a new key sharing strategy called SKN to improve the availability of keys. Users interact with each other through a streaming network, which is a fully connected network, to ensure that the same key is not stored in the same node.
Dai et al. [103] designed the SBLWT, a lightweight wallet architecture, which is based on TEE. The insecure storage module in the normal environment only has read access to the encrypted block header in the trusted environment, while encrypted messages can be proactively stored in the insecure space, thus ensuring security between message exchanges.
Unlike traditional forwarding wallets, Rezaeighaleh et al. [104] shared the keys of the main wallet and sub-wallets to enable the generation of various sub-wallet addresses in a transaction. And the address generation process in the subwallets is designed to secure its keys. Most importantly, there is unnecessary to back up the sub-wallets because the mastersub structure can derive the sub-wallets from the main wallet.
To defend against a single point of failure, Jian et al. [105] proposed a threshold-based ECDSA (T-ECDSA) scheme. When the number of participants is within the threshold, they created shared private keys to sign transactions. Participants outside the threshold take turns signing transactions. There is also another program [106] that uses T-ECDSA to design wallets. It combines multiple signatures into one signature. However, the design of the bloom filter protects the information of the participants on a small scale.

B. P2P NETWORK OPTIMIZATIONS
The transactions initiated by each node in Ethereum are transmitted through P2P networks to achieve self-governance without a third party; however, the lack of authentication and other features leads to a series of attacks, such as the eclipse attack [107]- [110]. An information eclipse attack occurs when an aggressor removes nodes from a network to restrict access to information from nodes.

Reference
Key Scheme [107] Sending requests to multiple peers [108] Ensure that node ids always exist in the query table [109] Analyze packets using a random forest model [110] Increasing the default number of peers Wüst et al. [107] proposed a novel eclipse bug, when the block height is n, a malicious node can obtain the (n + 1) th block by preventing a regularly functioning node N from receiving it. It invalidates subsequent blocks, even if node N may receive them. However, it offers some countermeasures. If there is a block request that is not corresponding, the block is requested from multiple peers instead of just one peer. This approach can solve denial of service attacks caused by eclipse attacks through multi-party collaborative governance. However, Marcus et al. [108] suggested a series of protection methods against eclipse attacks on Ethereum, two of which are also adopted by Geth. When a node restarts, the client's seeding is triggered every hour, or lookup() is called on an empty table which stores the information in memory, but the seeding is available only if the table is empty. However, node IDs should always be inserted into the table to prevent attacks. Specifically, Geth runs a lookup() on three random targets during seeding to add more legitimate nodes from the db which stores the information on disk to the table to prevent attackers from inserting their node IDs into an empty table during seeding.
Xu et al. [109] provided the ETH-EDS model for analyzing packets and identifying three features in packets for the random forest model, which is a classification model based on decision trees. It detects malicious nodes that isolate users, allowing users to defend their networks in real-time.
Henningsen et al. [110] proposed an optimization scheme for the false friend eclipse attack that exists in Geth. The attack can be deployed with just 2 IPs and loaded on the node immediately. The peer is the number of network nodes that can be connected, default by 25. It is similar to Wüst et al. [107] in that it increases the peers to 50 for increasing the probability of survival of spare nodes.

C. CONSENSUS LAYER OPTIMIZATIONS
The consensus layer and the incentive layer are interdependent. The design of the consensus mechanism directly affects the behavior of miners. Although many consensus mechanisms have been proposed, such as PoW and PoS, there is little regulation of the consensus or incentive levels.

Reference
Key Scheme [44] Execute variant transactions with several EVMs [47] Build the graph and analyze it to find fork attacks [111] Randomly select an EVM version to test transactions [112] Fuzz engine for parallel extraction of functions [113] Test EVMs with contracts and analyze results Fluffy [44] discovered two vulnerabilities, "Shallow copy" and "Ether Shift" in Table 2. It first picks test cases and then changes the transactions in those cases. Next, it puts these transactions into multiple EVMs and collects all the state and coverage at the end of the execution. Finally, it repeats the above steps until the state no longer changes.

VOLUME XX, 2022
As described in III-B, fork attacks might affect the security of blockchain in terms of consensus mechanism, Zhou et al. [47] developed DefiPoser to monitor fork behaviors. Figure 2 shows the process of DefiPoser, it heuristically prunes the patches after building the DeFi graph and then does a greedy search of the negative cycle in the directed transaction flow graph, which means finding all possible profitable cycles in the trade flow graph, to detect arbitrage transactions in cyclic or more complicated scenarios. A binary search of all the paths finds the most profitable one. If it is within the quantization threshold quantified by the Markov decision process, there is a chance to motivate a fork attack by miners using MEV.

FIGURE 2. Diagram of DEFIPOSER Core Process
Ethereum exists an EVMLab [111] library for interacting with Ethereum virtual machines (EVMs), which are officially used to analyze the bytecode of smart contracts. In this way, one version of the EVM is randomly selected for a single transaction on a smart contract, and then finds bugs.
Another library called LibFuzzer [112], was developed based on a tool chain LLVM written in C++. It generates N concurrent processes for functions in the contract and randomly assigns subsets to them, where one of the subsets will merge its generated corpus into the main set in the end. These corpora are used to find bugs using fuzz.
EVMFuzzer [113] is a tool for testing and evaluating EVM. It takes the target EVM and its API as input and then creates an execution environment for them to test and evaluate the EVM. In this process, multiple EVMs receive some of the same quality contracts that have been selected and output the results in the same format. It discovered a DOS attack on Geth, which was recorded as CVE-2018-19184.

D. SMART CONTRACT SECURITY OPTIMIZATIONS
The smart contract, which is a part of the DeFi project connecting the data and the application layer, might alter the state of a transaction, and cause errors. Therefore, it's critical to improve the security of contracts.

1) Smart Contract Vulnerability Detection
In this section, we will introduce the methods in the Table 9 which were proposed for detecting the vulnerabilities in the smart contract. Much research [52] [56] [115]- [124] has been undertaken to discover contract vulnerabilities using various technological tools, such as formal verification, symbolic execution, and machine learning.
Combined with dynamic testing extends the ability of symbolic execution techniques to detect unknown vulnerabilities, thus improving the robustness of programs. Figure 3 shows an overview of ILF [116] that combines fuzzing, machine learning, and symbolic execution. The system used the symbolic execution for a portion of the contracts to generate transaction sequences as the training dataset for a new model consisting of GRU which is a type of neural network and a fully connected network so that the model can learn the fuzzing in the state after the symbolic execution to test contracts with high coverage.

FIGURE 3. Schematic Diagram of ILF Process Framework
As our best known, Oyente [56] is the first detection tool using symbolic execution for smart contracts. It examines the logic of the contract code and generates control flow graphs. It then instructs the Ethereum initial state simulation run to construct feasible data flow operations. After that, the appropriate analysis methods discover various vulnerabilities.
Chen et al. [114] counted the frequency of opcodes in the contract, and in addition, it analyzed the features of malicious accounts through the ether flow graph. Then, for vulnerability identification, the XGBoost model [125], which is a gradient model based on the decision tree, was built using the features. This strategy can be utilized before contract deployment because it does not need attributions about the transaction.
Amani et al. [115] formalized the EVM in terms of bytecode using Isabelle/HOL and built a double verifier logic to reason about the program. They then demonstrated the safety of the system. However, owing to the development of Ethereum, it cannot describe the complete semantics of the smart contract in several versions.
DefectChecker [52] uses the commands provided by Geth to disassemble the contract bytecode into opcodes and then split the opcodes into multiple base blocks, executing different instructions for each block and defining eight types of rules to detect vulnerabilities. It analyzes specific features of the vulnerability and then different generic specifications are set for detecting the vulnerability based on [49].
SmartEmbed [117] consists of two main aspects, structured code embedding that converts code into word vectors and similarity checking that can detect the similarity of different vectors. It marks Solidity codes and a new code embedding is generated using word embedding techniques, and finally, bugs could be found within a threshold by comparing the similarity between vectors. Clairvoyance [118] designs several path protection techniques for reentrancy vulnerability and used taint analysis techniques to reduce the phenomenon of false positives from other tools. More importantly, this lightweight approach allows analysis of cross-contract behavior.
Up to May 2022, the compiler of Solidity has over 90 versions, each with significant updates [126]. As a result, the compiled bytecodes with the same logic are diverse and noisy. To solve this problem, Huang et al. [121] labeled the data and reorder the opcodes. This process ignores all irrelevant instructions, then it analyzes the bytecode execution process and slices the data by the label to reduce the noise impact of meaningless code. Subsequently, This method uses an unsupervised graph embedding algorithm to deal with the smart contracts, each slice of code is encoded as a vector and their similarity is compared for vulnerability detection.
Smartian [122] just started statically analyzing the contract bytecode and collecting the data stream. The seed pool ini-VOLUME XX, 2022 tialization predicts the sequence of transactions in some data stream and considers them as seeds for initialization. Finally, the seeds, which are the sequences of generated transactions, are used to guide the fuzz of the data flows.
Another methodology similar to ILF uses high-quality transaction sequences to direct symbolic execution in order to discover susceptible contracts. SmarTest [120] based on VeriSmart [119], it first performs symbolic executions on the contracts in the training dataset, each lasting long enough to gather all the fragile transaction sequences, and then utilizes these fragile transaction sequences as the collection of training sequences for the language model. The goal of training the language model is to create a training corpus Y from which counts of n tuples are gathered to guide the symbolic execution to find fragile transaction sequences.
Nam et al. [123] examined smart contracts using the alternating-time temporal logic (ATL) model, a formal verification approach that determines if smart contracts in Ethereum meet certain features. It also translates the Solidity to MCMAS, an ATL checker that requires input. It allows developers to validate the attributes that they want to examine.
EXGEN [124] transforms the contract source code or bytecode to an abstract syntax tree (AST), which is subsequently converted into an LLVM representation of the unified form. Then, using symbolic execution techniques, all restrictions are removed. Next, it uses a solver to solve the constraints and determine the sequence of vulnerabilities. Finally, the sequence is verified before uploading to the chain.

2) Smart Contract Operation Regulation
However, Ferreira Torres et al. [127] showed that contract vulnerability detection could increase contract defensibility, but assaults have not decreased, indicating that contract regulation has to be further improved. It has been studied in [80] [127]- [131], and we briefly introduce Sereum [80] in Figure 4, a tool focused on runtime monitoring and verification of the reentrancy bug.
The transaction manager converts all control flows into conditional jump instructions in the bytecode interpreter. The taint engine identifies data flows in conditional jump instructions, tagging storage variables as the key variables and writing into the lock. The attack detector detects the variables. If the modification occurs, the whole transaction rolls back to the point where the variable was marked, which is the starting point of the entire transaction. Sereum defends online smart contracts from reentrancy attacks, but such systems are difficult to expand to additional weaknesses. EVMpatch [130] intended to address this issue by providing a bytecode rewriting engine that updates contracts currently on the chain, and the patch program is readily scaleable to other flaws. Automated analysis tools and vulnerability revelations detect and generate reports on vulnerabilities, and bytecode rewriters receive vulnerability reports and patch the contract at the byte level. The testing module then verifies that the patch will work with the previous transactions. After the test passes, the deployer uploads the patched contract to Ethereum.
Many tools only detect bugs but do not quantify and track stolen assets. To monitor stolen assets, the Eye of Horus [127] employs knowledge graph technology. It extracts data streams of vulnerable transactions using taint analysis. Then it analyzes the input data relationships and finds attacks from the generated logs. Finally, it obtains the attacker's addresses and timestamps, then loads the transaction information into a graphical database for access to the asset flow.
AEGIS [128] constructed some control flow and data flow patterns describing the vulnerabilities and modified the EVM so that it could revert to transactions against patterns during contract operation. Anyone can submit a pattern when discovering a new vulnerability. All voters in the chain then determine whether the pattern can be added to the list.
SODA [129] is an online detection framework for a smart contract that includes a manager, information collector, and logger. It provides registered and unregistered APIs to APPs and requires the APP to send operational information, block numbers, and different functions to the manager. The information collector collects all blocks, transactions, and contract structure information for vulnerability detection, and the logger issues an alert if it finds anomalies. This framework with detection APPs is compatible with multiple blockchains.
Nguyen et al. [131] proposed SGUARD, which evaluates control dependencies to discover malicious opcodes once all traces are enumerated at the bytecode level and located to external callers. Finally, the flaw is corrected through patching at the source code level. Correspondingly, it analyzes all types of data dependencies, including memory, storage, and stack. However, the limitation of this work is that there is no explicit number of iterations to obtain all data dependencies in smart contracts.

E. APPLICATION LAYER OPTIMIZATIONS
There are some market manipulations at the application level that can lead to damage to user assets, but some research and works exist to safeguard various applications, including optimization tools and insurance.

1) Optimization Tools
Although there is a correlation between the various layers, methods for lower levels can not fully recognize the attacks against the application layer. Some research [10] [58] makes contributions. Wang et al. [10] designed Blockeye to divide the detection work into two phases. In Figure 5, the first phase uses symbolic execution analysis in oracle to check whether state data streams are externally manipulated to detect vulnerable DeFi. During the second phase, transaction monitors under the chain collect transactions to extract the features and further analysis to monitor the attack.

FIGURE 5. Diagram of BLOCKEYE Core Process
DeFiRanger [58] is a price manipulation checker that first collects transactions on Ethereum and constructs a tree structure on the flow of cash. Then it defines the style based on DeFi attack behavior and recovers the low-level semantics to high-level semantics. Finally, the system detects attacks and analyzes them to generate a report based on the style and high-level semantics.

2) Insurance
As the DeFi market expands, insurance is critical to ensuring its stability [132]. Our research divides risks in DeFi into market risks, technical risks, and credit risks. However, the enormous damages experienced by regular users result from technical or credit risks. So there require insurance systems to safeguard the properties of users, and they can be classified as centralized and decentralized.
For example, Smart Contract Cover, which provides smart contract insurance, is evaluated by the Nexus Mutual [132] internal assessors to determine the cost of the insurance. It is self-governed by the members who own the NXM token of the pool built with "mutual", making the risk evenly shared.
Etherisc [133] is a centralized platform that offers several insurance programs, including crypto wallets and collateral. As for crypto wallets, it guarantees the wallets against hacking and the risk of theft. Another one refers to the protection of the price of the collateral provided by the borrower within a certain range. For example, when the price of the collateral is reduced by more than 90% due to a big drop in the market, the insurance will pay the original price to the borrower. VOLUME XX, 2022 Opyn [134], which focuses on insurance for option trading products, enables users to choose options to hedge risks based on ERC20 tokens, and the protocol is automatically performed by smart contracts for multiparty governance. It also provides audit services and publishes all contracts, offering bounties for contract optimization.
Bridge Mutual [135] allows users to add insurance to products of their choice, and the decentralization makes the entire coverage process transparent for insurance purposes. To achieve risks shared, thousands of pools covering diverse platforms, stable currencies, and exchanges are coefficient.
Bright Union [136] integrates most insurance in the industry and licenses to encrypt them to enable mutual coverage without a license. It can improve cost performance for higher complete coverage by combining various insurance.

VI. CHALLENGES AND FUTURE DIRECTIONS A. CHALLENGES
DeFi is a mechanism built through blockchain technology as the underlying technology that does not rely on the operation of a centralized service. The biggest advantage of DeFi is that funds are automatically traded through technical protocols, thus eliminating the need for human intervention, which increases liquidity in the market and thus facilitates financial transactions. However, DeFi still has challenges, and the following issues can be solved to better facilitate the development of the ecosystem.
(1) Data issues remain a challenge. Technologies such as oracle are already being used to solve the problem of data synchronization, and the key is protected by wallets to ensure the encryption process, and the improved transmission protocols are designed to secure the data transmission process.
However, due to the complete autonomy of blockchain, the data cannot be modified after it is transmitted on the chain in principle. When there is an error in the data transmission process or the source of data, it will lead to problems in the whole system. The technology in these aspects is not mature enough and cannot fully guarantee the correctness of data without affecting the other performance of the system, such as scalability, and throughput.
(2) Key technologies of blockchain are not mature enough. Starting with Bitcoin, the consensus mechanism is one of the basic technologies of blockchain. Despite the fact that it has fewer vulnerabilities, it still has a series of actions against consensus rule flaws that may result in forking. More importantly, the loss it causes is significant since forking is irreversible. The smart contract is the basis of various dapps, the vulnerabilities that exist in it are also endless. Due to the rapid development of the smart contract, there is still a lack of effective tools for potential vulnerabilities in it.
(3) The technology features are not fully utilized, but there is just migrating the mechanisms that already exist. The various economic instruments that already exist lead to the failure of technical indicators. Because DeFi is not fully integrated with the real world at present, it relies on a variety of virtual indicators for the prices of financial products. However, when some data beyond the normal range enters the system, it can lead to errors. And since there is no trusted third party to guarantee DeFi, it has to rely on various protocol stacks, which leads to fragmentation and uncertainty of assets.

B. FUTURE DIRECTIONS
Since Blockchain 2.0, it not only has cryptocurrency, but a wider range of applications in the financial domain with the smart contract. However, due to the combination of various protocol stacks and the development of blockchain technology, the security of DeFi is also gaining attention. Therefore, we offer some possible future directions for enhancement.
(1) An effective multi-layer vulnerability detection tool is still lacking. The detection method designed for a particular layer cannot detect information at higher levels. For example, detection tools designed for the smart contract just make use of the information in the smart contract, so they cannot detect the features at the application level. Most application-level attacks need to combine multiple layers, so joint detection of vulnerabilities between multiple layers is worth investigating.
(2) The dynamic supervision techniques for each layer need to be improved. There are many static analysis methods and detection techniques, but these techniques are not able to prevent the damage caused by the attack timely when the attack occurs. Efficient dynamic supervision technology could solve this dilemma, but there is a lack of efficient supervision technology for various layers, including the data layer, network layer, and application layer.
(3) Decentralized applications should be fully integrated with technical features. The current application design copies other existing frameworks, which ensures the usability of the application but sacrifices security. For example, many dapps in DeFi simulate the real-world design of financial product data, but they do not fully take all the circumstances into account. When there is a larger number of assets than the existing assets suddenly entered the system, it would result in the existing proportion of assets extremely shrinking thus market participants cannot have the right to master the assets. Therefore, the dapps should take full advantage of the technical features instead of abandoning the design framework and thus leading to an imperfect combination.

VII. CONCLUSION
DeFi is a new type of platform based on blockchain technology that may increase the number of financial transactions while also efficiently enhancing the development of finance. Although DeFi provides several advantages, its security must also be considered during the development phase.
This paper first introduces various basic concepts of DeFi and then focuses on the security of DeFi. First, we start with a systematic analysis of each layer and a series of vulnerabilities are summarized. For each vulnerability, we investigate real-world attack cases and explore the vulnerabilities used in each case. We then summarize the studies on optimizing for these vulnerabilities at each layer. Finally, we summarize the dilemmas and security issues encountered.
In terms of optimization, comprehensive attack analysis and monitoring are critical to constructing a robust defense. There are various possible future trends. For example, (1) The comprehensive analysis of the properties at each layer and the design of efficient detection techniques. (2) A combination of static detection and dynamic monitoring approaches should be used to safeguard DeFi for each layer. (3) Tools should be completely functional in terms of technological aspects.