什么是 Front-running

要介绍MEV，就绕不开Front-running（直译为抢跑），也称为Priority Gas Auctions (PGAs)，实际上是一个意思。

我们都知道，常规意义上，在以太坊上提交交易是一个看似有序的过程，现在重新审视一下这个过程：

用户需要在钱包构建交易，并签名，钱包后端会将该交易广播到 P2P 网络；
该交易首先会进入各个节点的 mempool，按照一定的顺序排列；
矿工从 mempool 中选取合适的交易进行打包，挖矿出块，该交易就成功上链了。

然而事实并非如此，和看似有序的交易打包过程相比，以太坊更像一个?黑暗森林?[1]。

由于每个以太坊全节点均会维护一个 mempool，上面的未打包交易是清晰可见的。有这么一群人，这群人会不分昼夜地审视 mempool 中未打包的交易，通过某些技术手段判断这些交易执行是否是有利可图的，并利用较高的 gasPrice 抢先执行交易。举个最直接的例子，当这些人发现某鲸鱼地址提交了在 Uniswap 大量买入某数字货币的交易，他们会利用更高 gasPrice 发布一个买入交易。通常情况下，矿工会优先打包 price 更高的交易，将抢跑者的交易插入到鲸鱼交易的前面，这样鲸鱼地址的买入就为抢跑者”抬了轿子“，通过这种方式获得利润。

部署蜜罐合约认识抢跑

我们引用之前其他人做过的实验，通过部署一个蜜罐合约来研究抢跑行为。部署蜜罐合约如下，用户必须调用合约中的 take 方法，并正确提交 secret 才能拿走合约中的 ETH：

当发起交易的时候，该交易会首先提交到 mempool 中，抢跑者会不断读取 mempool 中的交易。并且对这些交易模拟执行，当发现有利可图时，比如执行完之后发现可以获取到一定数量的 ETH 或者 ERC-20 代币，则将该交易进行抢跑。

可以看到，在发起的第一笔正常交易时，指定了 33 gwei 的 gasPrice：

该交易调用了蜜罐合约的 take 方法，但是交易执行完之后，却没有收到 ETH奖励。而查看合约的 event 之后，我们发现不止有一个和该蜜罐合约进行了交互，并且紧跟在初始交易的后面发生：

除了 0xe0c3dc 交易，其他的交易都是抢跑者发起的交易，其中只有一笔交易成功提走了合约的奖励 ETH。

0x15becbfbd33237bb28c8925870bedbf8b80cbe9967e89ea72239d418e931d5c7（失败，122.425344303?Gwei）
0x5169bccd1893130995ebc25fa374366284b723ded44f379d0977af3f144d1a8f（成功，122.425344305 Gwei）
0x2f5e7b565e8280826af0a9f492d53fac1b690848df39b98b22f614143d633a4d（失败，43 Gwei）

可以看到，最终 gasPrice 最高的交易成功提走了蜜罐合约的奖励，哪怕只比别人高了0.000000002 gwei：

那么问题来了，蜜罐合约并没有发布源码，这些抢跑者是如何在如此短的时间内判定该交易值得被顶替呢？或者说如何判定该交易是有价值的？这里就涉及到交易模拟执行技术。

抢跑关键技术：交易模拟执行

抢跑机器人如何判断某个在 mempool 的交易是否是有利可图的呢？这里需要介绍交易模拟技术。

交易模拟执行本质上是给定交易的输入、给定需要模拟的状态树，通过这两个数据，由 EVM 模拟执行一次并输出 trace 结果。

实现起来其实并不难，如果我们维护一个 archive 节点或者 trace 节点，RPC中会有 trace_call 这个 endpoint，通过 tace_call 我们可以实现交易的模拟执行，可以看到交易中的内部交易、状态变化等。

比如我们需要模拟执行交易：0x5169bccd1893130995ebc25fa374366284b723ded44f379d0977af3f144d1a8f，并且需要在历史状态上执行，我们则需要首先维护一个 parity 的 archive 节点（archive 节点会保存全部的历史状态），并且执行以下命令：