Analyze the principle of Ethereum’s preemptive transaction and its solutions

0
7

 731 total views

As a general user, you can deal with preemptive transactions by setting lower transaction slippage and higher gas fees.

Written by: DeGate

This article aims to comprehensively analyze the attack behavior widely existing on the Ethereum blockchain: Front-Running (front-running transaction), through the research of its principle, find the most effective solution, and finally help DeGate users avoid this serious problem. Attacks that harm their interests.

Front-Running and Mempool

To put it simply, Front-Running refers to the attacking behavior of grabbing the user’s benefit by setting a higher Gas fee to complete the attacking transaction in the process of a normal transaction waiting to be packaged. Mempool is a group of Ethereum transactions that have been broadcast to the network and are waiting to be packaged into blocks. It is the prerequisite for Front-Running to be implemented. The runaway robot continuously scans the transactions in Mempool to analyze and find targets that can be attacked. . The picture below is a Mempool browser. You can subscribe to transactions in Mempool by setting various filters and view all the details of these transactions.

Among all Front-Running, the most typical and most harmful is Sandwich Attacks for AMM transactions. In addition, there are also arbitrage, clearing transactions, lightning loans, etc. that use system vulnerabilities to make profits. The attackers are numerous and controlled by automated scripts, and they are never tireless. Therefore, any profitable transaction will suffer from their saturation attack, and there is almost no possibility of being spared.

Next, we focus on the analysis of the sandwich attack.

Sandwich Attacks

Real attack case

First, let’s look at a real sandwich attack case.

Analyze the principle of Ethereum's preemptive transaction and its solutions

As can be seen in the above figure, three transactions are packaged in the same block, and a normal transaction is sandwiched between the two attack transactions (marked by hackers). The specific process is as follows:

  1. The user first initiates a normal transaction, buys DG with 237000.705USDC, and sets the Gas Price to 40.5Gwei;
  2. After the runaway robot detects this profitable transaction, it immediately launches an attack and initiates a buy transaction, setting the GasPrice to 49.9Gwei, and successfully snatching away the user’s normal transaction by virtue of the Gas competition mechanism;
  3. At the same time, the robot sends another sell transaction, setting GasPrice to also 40.5Gwei, because of the time sequence, it is close to the user’s normal transaction completion.

A perfect run attack is completed, and the bot will earn a total of 16448.012-16310.3-15.2-10.61 = $111.9, including a normal transaction attack, which is vividly called a sandwich. attack.

Principle explanation

In order to better explain the attack principle, we add some relevant background knowledge.

We know that today’s mainstream DEX such as Uniswap, etc., all use the AMM (Automated Market Maker) mechanism, and their prices follow a constant product formula. For example, in Uniswap to establish a liquidity pool of A tokens and ETH, the number of A is 1000 and the number of ETH is 100, then the product of the two quantities is 100000, and the current price of A is 0.1ETH. When Alice tries to use 10 ETH to buy A from the pool, the amount X of A he gets can be derived using the following formula (Note: To simplify the calculation, the following fees are not considered):

(1000-X)*(100+10)= 100000,X = 90.9

In this transaction, the price of A is 10/90.9 = 0.11. Compared with the original price of A, the price slippage is:

(0.11-0.1)/0.1*100% = 10%

A single transaction caused a 10% slippage in the currency price. It can be seen that the more liquid pools, the more likely it is to have slippage when encountering large transactions. And if you can buy A before the user’s normal large-value transaction (it is expected that the transaction will have a large slippage), and then after the user’s normal transaction, sell the newly bought A, you can get a sum A lot of money. Following the previous example, suppose that before Alice’s transaction, Bob first spends 5 ETH to buy A, and then after Alice’s transaction is completed, Bob sells the previously bought A. Let’s see what the result will be.

The first is Bob’s runaway deal:

(1000-X)*(100+5) = 100000, X = 47.62

That is, Bob bought 47.62 A with 5ETH

Next is Alice’s normal transaction. Note that the number of A in the liquidity pool becomes 952.38, and the number of ETH becomes 105:

(952.38-X)*(105+10) = 100000, X = 82.81

Finally, Bob sells 47.62 transactions of A. At this time, the number of A in the liquidity is 869.57, and the number of ETH is 115:

(869.57+47.62)*(115-Y)= 100000,Y = 5.97

Through this runaway attack, Bob made a net profit of 5.97-5 = 0.97 ETH, while Alice’s net loss was 90.9-82.81 = 8.09 A. Bob obtained his own profit by making Alice suffer a greater slippage loss!

Of course, the actual rush attack will be more complicated, and the attacker needs to perform more sophisticated calculations in order to achieve the following two goals:

  • Let the user’s trading results infinitely approach the maximum slippage (max_slippage) set by the user, in order to achieve the theoretical maximum arbitrage space
  • Strike a balance between fee competitiveness and revenue, and try to win the competition with other robots as much as possible

Analyze the principle of Ethereum's preemptive transaction and its solutions

We use diagrams to better describe this process:

  1. At point A, the user intends to invest in_amount(user) USDT to buy ETH. This transaction will normally push the current state to B, and the user has set the maximum slippage as B(max_slippage);
  2. The runaway robot detects this transaction and performs a buy transaction of in_amount(robot) USDT before the user transaction, pushing the current state to A’;
  3. The user’s transaction is subsequently executed, and the maximum slippage B (max_slippage) set by it is reached;
  4. The runaway robot sells the ETH bought in step 2, and the state reaches point C, and out_amount(robot) USDT is obtained
  5. Run the robot to get the income out_amount(robot)-in_amount(robot)-handling fee

solution

Now that we have seen the lethality of Front-Running, what can we do to prevent a start-up attack?

As a general user, there are several ways to deal with Front-Running:

  • Set a low trading slippage, such as 0.1%, which will make the runaway robot lack profitable space. Disadvantages: Too low slippage makes large transactions easy to fail, and failed transactions still need to pay high fees.
  • Increase the gas cost, which will increase the cost of the robot’s attack. Disadvantages: This also increases its own transaction costs.

It can be seen that the above solutions are helpless and have various shortcomings. Fortunately, many teams have realized the harmfulness of Front-Running and have put forward many constructive solutions. First, through the analysis of the entire hunting process, we can conclude that to achieve Front-Running, several elements are required:

  • Transaction publicity: you can get the transaction details in Mempool
  • Ethereum transaction execution mechanism: the transaction can be completed first through gas competition
  • AMM trading curve mechanism: the constant product mechanism can cause greater slippage

Then the countermeasures are to make a fuss on these elements separately.

Transaction publicity

Since the robot decides whether to launch an attack by analyzing the transactions in Mempool, then we directly encrypt the transaction information so that the robot cannot see or understand it?

Someone in the community proposes to use the zero-knowledge proof technology zk-SNARKs to achieve the above goals, that is, to use zk-SNARKs to encrypt and hide the information of each transaction, so that robots cannot start.

However, the current scheme is not mature enough, and there are defects that require higher gas costs and may be used for blocking attacks, leading to systematized overall liveness.

Ethereum transaction execution mechanism

The current Ethereum transaction execution mechanism is completed through gas competition, that is, whoever pays high gas fees, miners will give priority to packaging whose transactions, then if we bypass this mechanism and send the transaction to the miner for direct packaging, It eliminates the possibility of the grab-run robot attacking in the middle

Therefore, a solution similar to Layer 0 has also been applied, such as the Taichi service of Spark Mine Pool. Users can directly set Taichi’s Ethereum node in MetaMask, so that the transaction is directly packaged without appearing in Mempool. However, the disadvantage is that there is a certain degree of uncertainty in the timeliness of being packaged.

In addition, solutions with similar concepts such as ArcherSwap build a bridge between traders and miners. Traders can allow miners to directly package their transactions in the form of rewards, which avoids the possibility of being Front-Running. Although there is a feeling of paying a protection fee to avoid being attacked, it actually reduces the cost of traders and has the advantage of not charging transaction failure fees.

AMM algorithm optimization

Under the AMM mechanism, large transactions produce excessive price slippage (can be understood as a temporary error price), which is the profit margin of Front-Running. If there is an AMM mechanism, it can reduce the impact of large transactions on subsequent transaction prices. , You can effectively prevent Front-Running attacks.
As early as 2018, Vitalik provided a solution in the Ethereum technical community. When an exchange transaction occurs, the transaction pool price will not be adjusted to the real price immediately, but within a few minutes, it will slowly move towards the real price, which is like The trading pool has a lot of liquidity out of thin air, so we call this technology Vitrual Balance (virtual balance) technology. This new mechanism can greatly reduce the profit margins of arbitrageurs, effectively defend against Front-Running attacks, and increase the revenue of liquid market makers. It can be said to serve multiple purposes. 1inch mooniswap is an implementation version of this solution.

Increase liquidity

In addition, another idea is to increase the liquidity of a specific price range in the trading pool as much as possible. The greater the liquidity, the smaller the slippage. When the liquidity reaches a certain level, the runaway robot will lose its profit. Space, Uniswap’s V3 version’s focused fluidity feature is an effort made in this regard.

Look to the future

We have reason to believe that with the unremitting efforts of various teams, with the continuous evolution of various solutions, and the successive landing of the new generation of AMM, the second layer of Ethereum and other technologies, we will soon be able to provide users with a better solution. A fair and safer chain trading environment.

Let’s block ads! (Why?)

Disclaimer:

Blockcast.cc does not endorse any content or product on this page. While we aim at providing you all important information that we could obtain, readers should do their own research before taking any actions related to the company and carry full responsibility for their decisions, nor can this article be considered as investment advice or recommendations. Every investment and trading move involves risk, you should conduct your own research when making a decision.