1. Introduction
Decentralized Finance (DeFi) is an important development direction in the current financial innovation field. In DeFi, the concealment of transaction information and the maintenance of user privacy are crucial. With the continuous expansion and deepening of DeFi, various projects are emerging, full of vitality. The application of Zero-knowledge proof (ZK) technology has opened up new possibilities for privacy protection in DeFi. ZK technology allows one party to prove to another that they know certain information without revealing any specific details about that information. The application of this technology in DeFi projects such as ZigZag, unyfy, and OKX's ZK DEX greatly enhances the privacy protection capabilities of DeFi, especially for the protection of transaction information. It is foreseeable that the widespread application of ZK technology will bring innovation to the way DeFi and the entire cryptocurrency field are handled, driving the future development of the entire industry and achieving significant breakthroughs.
2. Privacy Challenges in DeFi
There are no secrets on the blockchain, and the data transparency of DeFi is indisputable. For example, using a transaction on Uniswap V3 as an example, we can easily view the details of the transaction on the Etherescan website (as shown in Figure 1). Key information such as the sender (From), receiver (To), transaction amount (Value), and transaction fee (Transaction Fee) in these transactions are publicly accessible.
Figure 1 Details of a transaction publicly available on Etherescan
We can also view all the transaction records under the address 0x3A4D…a6f2 (as shown in Figure 2), and under certain conditions, we may even speculate on the real identity of this address in the real world.
Figure 2 All transaction lists for a specific address are publicly available on Etherescan
However, the data transparency of DeFi may have some adverse effects. If you are a DeFi whale, each of your transactions may attract market attention. For example, when a whale withdraws 11.24 million WOO (equivalent to about 4.2 million USD) from Binance, this transaction may attract widespread attention. Similarly, large payments or institutional-level trading activities may also attract public attention.
Other market participants may make buying and selling decisions based on these trading activities, which may have a detrimental impact on your investment strategy. For example, if you have invested a large amount of funds in a project, once your transactions are noticed by the market, other investors may follow suit, causing the asset price to rise and increasing your investment cost. In addition, your selling operations may also trigger market panic, leading to price declines and affecting your investment returns.
This situation highlights the urgent need for privacy protection in DeFi projects and for users. If we do not want our transaction details to be publicly known, we can choose to keep certain information about DeFi transactions private.
ZK technology can hide transaction details while ensuring the legitimacy of transactions. Users need to submit two types of information: a transaction with partially hidden details (such as the recipient or amount of the transaction), i.e., a private transaction, and a ZK proof about these hidden details. Verifying the legitimacy of a private transaction is essentially verifying the corresponding ZK proof.
3. Unlocking the Potential of DeFi: Opportunities Brought by ZK Technology
3.1 The Role of ZK Technology in Resisting Front-Running Transactions
Suppose you are fortunate enough to learn that a large company is about to purchase a large amount of a certain asset. You may choose to purchase this asset before the company does. Then, when the company's large purchase behavior drives up the asset price, you can sell it to make a profit. In this case, your transaction ahead of the company's constitutes a front-running transaction.
Front-running transactions are an investment strategy in financial transactions, usually occurring on exchanges such as Uniswap. This is because transactions on the blockchain are public, and transaction confirmation takes a certain amount of time. Therefore, some malicious traders may use higher gas fees to prioritize their transactions for mining confirmation, in order to achieve front-running transaction goals.
Front-running transactions can cause harm to other traders because they alter the original trading environment, making it difficult for other traders to proceed with their planned transactions. On the other hand, the purpose of attackers initiating front-running transactions is to profit for themselves by obtaining profits before price changes. Therefore, many DeFi projects are also trying various ways to prevent front-running transactions from occurring.
ZK technology can play a key role in resisting front-running transactions. Below, we will use the example of a sandwich attack in decentralized exchanges (DEXs), which is also a common type of front-running transaction, for case analysis.
Case Analysis: Sandwich Attacks in DEXs
What is a sandwich attack?
Suppose there is a liquidity pool on a DEX with a reserve status of 100 ETH / 300,000 USDT. Alice initiated a transaction to purchase USDT, exchanging 20 ETH for USDT. When she submitted the transaction, the DEX returned a result based on the current liquidity pool's reserve status, telling Alice that she could buy approximately 50,000 USDT. However, in reality, Alice only received 45,714 USDT.
Here, let's first understand why Alice was able to purchase 50,000 USDT with 20 ETH. The DEX used an Automated Market Maker (AMM) model, employing the Constant Product Market Maker (CPMM) algorithm to automatically calculate buying and selling prices. CPMM is a widely used automatic market maker algorithm that maintains liquidity supply and automatically adjusts asset prices by keeping the constant product of two assets in the trading pool. In this example, the quantity of USDT that Alice could buy was calculated using the formula 50,000=300,000-(100*300,000)/(100+20) (assuming no fees).
Alice did not receive the expected amount of USDT because she was subjected to a sandwich attack.
Sandwich Attack
The sandwich attack mainly occurs in AMM-based DEXs. In a sandwich attack, the attacker places two transactions around the victim's regular transaction to manipulate asset prices and profit from the victim's loss. These two transactions are the front-running transaction and the follow-up transaction, with the transaction before the regular transaction being the front-running transaction and the transaction after the regular transaction being the follow-up transaction.
So, how exactly did the sandwich attack on Alice unfold? See Figure 3.
Figure 3 Sandwich attack process
Attacker's front-running transaction: Before Alice's purchase of USDT transaction was executed, the attacker also initiated a transaction to purchase USDT (front-running transaction), exchanging 5 ETH for USDT. Moreover, the attacker paid a higher gas fee to the miner for this transaction than Alice, so the attacker's transaction will be executed before Alice's.
After the attacker's purchase of USDT transaction was executed, they obtained approximately 14,286 USDT from the liquidity pool, where 14,286≈300,000-(100*300,000)/(100+5). The reserve of the liquidity pool changed from the initial state of 100 ETH / 300,000 USDT to 105 ETH / 285,714 USDT. However, during the time between Alice submitting her transaction and it being executed, she was unaware of the change in the reserve status of the liquidity pool.
Victim's regular transaction: Subsequently, Alice's regular transaction began to execute.
After Alice's purchase of USDT transaction was executed, she obtained 45,714 USDT from the liquidity pool (based on the constant product function, 45,714≈285,714-(105*285,714)/(105+20)). The reserve of the liquidity pool changed from 105 ETH / 285,714 USDT to 125 ETH / 240,000 USDT. Therefore, Alice should have been able to buy 50,000 USDT with 20 ETH, but due to the changes in the liquidity pool caused by the attacker's transaction, she could only buy 45,714 USDT. Alice incurred a loss of approximately 4286 USDT (4286=50,000-45,714).
Attacker's follow-up transaction: Finally, the attacker initiated another transaction (follow-up transaction), exchanging the 14,286 USDT they just bought for ETH.
After the attacker's follow-up transaction was executed, they withdrew 7 ETH from the liquidity pool (based on the constant product function, 7≈125-(125*240,000)/(240,000+14,286)). The reserve of the liquidity pool changed from 125 ETH / 240,000 USDT to 118 ETH / 254,286 USDT. Therefore, the attacker initially spent 5 ETH but ended up with 7 ETH, gaining a profit of 2 ETH (2=7-5).
Throughout the entire process of the sandwich attack, the attacker initiated a total of two transactions, the front-running transaction and the follow-up transaction. The front-running transaction caused Alice to incur a loss of approximately 4286 USDT. The combination of the front-running and follow-up transactions resulted in the attacker profiting by 2 ETH.
In DEXs, the transparency of transactions is a key factor leading to the occurrence of sandwich attacks, especially in AMM protocols. These protocols make real-time transaction information on DEXs public, providing attackers with the possibility to observe and analyze transaction flows to find opportunities for sandwich attacks.
ZK Technology Can Resist Sandwich Attacks
The application of ZK technology can significantly reduce the likelihood of being subjected to sandwich attacks. By using ZK technology to hide transaction volume, asset types, user or liquidity pool balances, user identities, transaction instructions, and other protocol-related information, the privacy of transaction data can be effectively enhanced. As a result, attackers find it difficult to obtain complete transaction information, making the implementation of sandwich attacks more challenging.
Furthermore, ZK technology not only can resist sandwich attacks, but privacy transactions based on ZK can also increase the difficulty of judging user behavior models. Any third party attempting to analyze account transaction history, infer behavior patterns, explore active periods, transaction frequencies, or preferences through collecting blockchain data will face challenges. This analysis, known as behavior model inference, not only violates user privacy but also paves the way for honey pot attacks and phishing scams.
3.2 Preventing Liquidity Manipulation Based on ZK Technology
Liquidity manipulation and front-running transactions are both attack methods in DeFi, both involving using market information and transaction speed to gain benefits, but their specific strategies and operations are different.
Front-running transactions use information advantages, while liquidity manipulation uses market activity to mislead other traders. The former mainly profits from obtaining and using undisclosed important information, while the latter misleads other investors by creating false market activity, leading them to make unfavorable trading decisions.
ZK technology can not only play a key role in resisting front-running transactions but can also help prevent liquidity manipulation.
Case Analysis: Liquidity Manipulation Using Oracles
Imagine you are buying apples in a busy fruit market. The market price usually fluctuates based on changes in supply and demand. You typically observe the price for a period and then decide whether to buy based on the average price. Now, imagine a very wealthy buyer enters the market and is very eager to buy apples. They start buying a large quantity of apples, regardless of the price. This causes a short-term surge in the price of apples. If you still buy apples at this price, you may end up paying more than the actual value.
This example helps better understand the operation of the Time-Weighted Average Price (TWAP) oracle and the concept of liquidity manipulation. The behavior of deciding to buy apples based on the average price is similar to the operation of the TWAP oracle, and the wealthy buyer's large purchase of apples causing a price increase is similar to liquidity manipulation.
The TWAP oracle determines asset prices by calculating the average transaction price over a period of time. The closer the transaction is in time, the greater its impact on the average price. If someone makes a large number of transactions or trades with a large amount of funds in the short term, it may significantly impact the average price of the asset, which is liquidity manipulation. Liquidity manipulation artificially raises or lowers asset prices, leading to inaccurate price information. If someone intentionally tries to raise asset prices using the TWAP oracle, they can make a large purchase of the asset with a large amount of funds in a short period, causing a temporary price increase. If there is a significant increase in the asset price during this time window, the TWAP oracle may consider this higher price as the asset price.
Implementing liquidity manipulation on the TWAP oracle can have a significant impact on DeFi protocols, especially for low-liquidity emerging tokens. These DeFi protocols typically make financial decisions based on asset prices, such as liquidation and borrowing. If price information is inaccurate or unreliable, it may lead to incorrect decisions, resulting in losses for users. Therefore, preventing the TWAP oracle from being subjected to liquidity manipulation is crucial.
ZK Technology Can Resist Liquidity Manipulation
ZK-based technology can resist liquidity manipulation in the TWAP oracle. A smart contract can be designed to rely on the TWAP oracle to obtain asset prices. If an attacker engages in liquidity manipulation, the price obtained from the TWAP oracle may exceed the preset acceptable range. In this case, the contract will temporarily suspend its operation. Then, it will recalculate and confirm asset prices based on ZK technology.
To use ZK technology to calculate asset prices, you first need to add a wrapper contract to the TWAP oracle. This contract can directly access N price reports or record N checkpoint values at any interval. Once there are N data points available within a given interval, a ZK proof can be constructed to prove the median of the unsorted array of prices. The unsorted price array is labeled as a column vector x, with a length of N. The following is the process for calculating asset prices based on ZK technology:
- The proof can be verified in either of the following two ways, in both cases, the prover cannot arbitrarily choose a price array as input.
- Retrieve array values from contract storage and use them as public input for on-chain verification.
- Form a hash chain step by step through a hash function, representing the array as a single hash value, and use that value in on-chain verification.
There exists an N x N matrix A (square matrix) that, when multiplied by the column vector x, produces the column vector y, such that y=Ax. A is a reversible permutation matrix, but it is not necessarily unique due to the possibility of duplicate price values, and A only contains binary values.
The values in y are ordered, i.e., yiyi+1 i 0…N-1. It is reiterated that duplicate price values cannot be used.
The public output m of the circuit is the median value of y. The proof shows y⌊N/2⌋=m, where N is a static value at circuit compilation time and must be odd.
Based on the above process, ZK technology outputs a tamper-resistant median value m for asset prices. The median m can to some extent prevent liquidity manipulation. To achieve this, we need to limit the values of y so that in each block, the values of y are only inserted once or within an acceptable range of insertions.
3.3 Empowering Lending Platforms with ZK Technology
As mentioned above, ZK technology can resist front-running transactions and liquidity manipulation in DEXs. Can we further explore the potential application of ZK technology in other DeFi scenarios? For example, in lending, an important component of DeFi projects, ZK technology can also play a crucial role.
Key to Lending: How to Assess Borrower Credit
On traditional lending platforms, the loan application process typically covers five steps: application, credit assessment, loan approval, loan disbursement, and repayment. Among these, credit assessment is particularly important, as borrowers must prove their income and repayment capability. During the assessment, the platform conducts a thorough investigation of the borrower's credit history, including income, debt, and past repayment records, to ensure their ability to repay the loan. Only on this basis will the platform consider approving the loan application.
However, when you turn to DeFi lending platforms like Aave or Compound, the situation is different. Most DeFi lending platforms, due to their decentralized nature, lack traditional bank KYC (Know Your Customer) procedures and risk assessment processes, and cannot investigate the borrower's credit status through credit bureaus. In this case, you may wonder, how will my credit be assessed?
On DeFi lending platforms, you can prove your credit level through reputation tokens. Reputation tokens are a credit system based on blockchain technology, using digital tokens to represent and quantify a user's reputation. The quantity of reputation tokens becomes an important indicator for evaluating a user's reputation. The more tokens a user has, the better their reputation, and their credit rating increases accordingly, potentially allowing them to access more loan amounts on DeFi lending platforms.
However, the generation of reputation tokens relies on a user's transaction history and financial information, which may infringe on user privacy.
Assessing Borrower Credit: Reputation Tokens Based on ZK Technology
ZK technology can protect user privacy. The combination of ZK technology and reputation tokens can maintain and track a user's reputation in the network while protecting their privacy.
Users can use ZK technology to generate reputation tokens without disclosing their transaction history. On one hand, users can generate proofs of their transaction history based on ZK technology; on the other hand, a smart contract (commonly referred to as a reputation token generation contract) verifies this proof, and upon successful verification, reputation tokens are generated.
Furthermore, on some DeFi lending platforms that require over-collateralization, reputation tokens can lower the collateral requirements, addressing the issue of excessive collateralization and increasing market liquidity. The application of ZK-based reputation tokens is not limited to DeFi lending platforms; it can also be widely used in insurance, medical assistance, and other fields.
4. Conclusion and Outlook
This article explores various applications of ZK technology in achieving privacy protection in DeFi, particularly in resisting front-running transactions, liquidity manipulation, and lending. In the process of exploring DeFi, we face multiple challenges, especially those related to privacy and security. Privacy challenges in the DeFi ecosystem are a key issue, and ZK technology provides a unique solution that not only enhances privacy protection but also improves transaction efficiency and security.
Looking ahead, ZK technology may find further applications in deeper DeFi domains, such as liquidity staking, derivative protocols, real-world assets, insurance, and more. Salus is dedicated to researching and exploring the application of ZK technology in DeFi and other Ethereum application layer projects. We invite blockchain researchers, technical developers, and all professionals in the web3 field worldwide to work together with us to promote the deep development and widespread application of ZK technology, driving the development of DeFi and the entire industry.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
