（1000-X）\*（100+10）= 100000，X = 90.9

这笔交易中，A 的价格为 10/90.9 = 0.11，相比于原来 A 的价格，价格滑点为 :

（0.11-0.1）/0.1\*100% = 10%

一笔交易就让币价产生了 10% 的滑点，可见越是流动性差的池子，遇到大额交易，越是容易产生滑点。而如果，能在用户正常的大额交易前（预计该交易会产生较大滑点），抢先买入 A，再在用户正常交易后，将刚买入的 A 卖出，就可以获得一笔不菲的收益。沿用刚才的例子，假设在 Alice 的交易前，Bob 抢先花 5 个 ETH 购买 A，然后在 Alice 的交易完成后，Bob 再把之前买入的 A 卖出，我们看看会有什么样的结果。

首先是 Bob 的抢跑交易：

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

即，Bob 用 5ETH 购得 47.62 个 A

接下来是 Alice 的正常交易，注意此时流动池中 A 的数量变为 952.38，ETH 的数量变为 105：

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

最后 Bob 卖出 47.62 个 A 的交易，此时流动性中 A 的数量为 869.57，ETH 的数量为 115：

（869.57+47.62）\*（115-Y）= 100000，Y = 5.97

通过这一次抢跑攻击，Bob 净赚 5.97-5 = 0.97 个 ETH，而 Alice 净亏 90.9-82.81 = 8.09 个 A，Bob 通过使 Alice 蒙受更大的滑点损失来获得自己的收益！

当然，实际的抢跑攻击会更复杂，攻击者需要进行更精密的计算，以求实现以下两个目标：

• 让用户的交易结果无限逼近用户自己设置的最大滑点（max_slippage），以求达到理论上的最大套利空间
• 在手续费竞争力和收益之间取得平衡，尽可能的在与其他机器人的竞争中获胜

我们用图表来更好的描述这一过程：

1. 用户在 A 点，打算投入 in_amount(user) 个 USDT 购买 ETH，这笔交易正常会把当前状态推向 B，同时用户设置了最大滑点为 B(max_slippage)；
2. 抢跑机器人监测到这笔交易，先于用户交易之前，进行了一笔 in_amount(robot) 个 USDT 的买入交易，将当前状态推到 A'；
3. 用户的交易随后执行，达到其设置的最大滑点 B(max_slippage)；
4. 抢跑机器人把步骤 2 中买入的 ETH 卖出，状态达到 C 点，得到 out_amount(robot) 个 USDT
5. 抢跑机器人获得收益 out_amount(robot) - in_amount(robot)-手续费

解决方案

既然我们已经看到了 Front-Running 的杀伤力，那我们有什么办法阻止抢跑攻击呢？

作为一般用户，应对 Front-Running 可以有以下几种手段：

• 设置较低的交易滑点，比如 0.1%，这会让抢跑机器人缺少可盈利的空间。 缺点：滑点过低导致大额交易十分容易失败，且失败的交易仍然需要支付高昂手续费。 (责任编辑：admin)