最顶级的 MEV 机器人遭遇 750 万美元盗窃：Approval 是否是链上最被忽视的致命风险？

一款长期在以太坊上捕捉普通交易者的 MEV 机器人，最终落入了一个价值 750 万美元的“定制”陷阱。

在 6 月 21 日，以太坊知名的三明治套利机器人 Jaredfromsubway.eth 遭到攻击，其地址内的 WETH、USDC 等资产被转移，初步统计显示损失超过 750 万美元（目前公开的损失口径仍有所不同）。

令人关注的是，此次攻击并非由于私钥泄露或利用传统的智能合约漏洞，而是攻击者提前部署了大量虚假代币、流动性池和辅助合约，构建出可能存在套利机会的交易路径，诱使机器人在自动执行过程中向恶意合约授予 ERC-20 的 Approval，从而“合法”地转移了该 MEV 机器人的资产。

截至发文时，Jaredfromsubway.eth 已通过链上消息向攻击者发出公开呼吁，表示“如果在 48 小时内归还 2150 枚以太坊，愿意支付一半的白帽赏金，否则将采取所有可行的法律及执法手段追责”。

然而，即使是高度专业化的代码驱动的 MEV 机器人也会在 Approval 上遭遇麻烦，这不禁让人重新审视我们每天使用的“Approval”动作，究竟隐藏着多大的危险？

仔细回顾这次攻击事件，发现这并非一次偶然的漏洞，而是一场针对 Jaredfromsubway.eth 交易逻辑设计的长期围猎。

Jaredfromsubway.eth 一直是以太坊上最知名的三明治套利机器人之一。所谓三明治攻击，简单而言，就是机器人在发现即将发生的链上交易后，抢先在用户之前买入，推动价格上涨；等用户以更差的价格完成交易后，机器人再立即卖出，从中获取差价。

因此，该策略要求机器人持续监测链上交易，以极快的速度判断套利机会，组织交易路径，调用不同的代币和合约。这意味着，速度越快、覆盖的资产与协议越多，机器人能够捕捉的机会也就越多。

根据事后复盘，攻击者并没有直接攻击机器人的资金合约，而是花费数周时间构建一个看似能够盈利的交易环境：

简单来说，整个攻击完全针对 MEV 机器人的运行特点，先制造一个符合其盈利判断规则的环境，再利用其追求自动执行交易路径的机制，让系统主动交出资产调用权。

这也解释了为何连高度专业化的 MEV 机器人都会中招。

它能够计算价差、Gas 成本和交易顺序，但并不一定会对每个新出现的合约进行充分的身份验证。从这个角度看，普通用户的问题是“没有看懂就点了确认”，而自动化机器人的问题则是“没有确认就自动执行”。

表面上看，两者似乎截然不同，但底层风险却非常接近，因为他们都将授权视为完成交易之前的一个普通步骤，而没有清晰意识到它潜藏的高风险。

众所周知，在以太坊及 EVM 兼容链的 ERC-20 标准中，Approve（授权）是一个相当基础的设计。

然而，用户在钱包中直接转账时，通常调用的是 transfer，通常不涉及 Approve，只有在 DEX、借贷、质押或添加流动性等智能合约场景中，用户才需要允许智能合约代表自己调用代币，这时才涉及 Approval。

举个例子，当我们想在 Uniswap 上用 USDT 兑换 ETH 时，Uniswap 的智能合约无法直接从用户的钱包中提取 USDT，必须先执行一次 Approve，告知系统“我允许 Uniswap 划走我钱包中的 X 个 USDT”。

只要授权完成，获得权限的合约才能通过 transferFrom 在限制额度内调用用户的 USDT，后续的 Swap 才能顺利进行。

也就是说，Approval 本身并不是漏洞，而是 DeFi 正常运作的重要基础。问题在于，这类似于支付宝或微信的自动扣款权限：

用户虽然没有将账户密码交给商户，但却允许商户在约定的范围内主动扣款，只要授权仍然有效，后续扣款无需用户再次输入密码或逐笔确认，这就自然带来了潜在问题。

首先是无限授权的问题，用户往往将一次交易变成长期权限。为了减少重复授权带来的操作和 Gas 成本，许多 DApp 会默认申请一个较大的授权额度，即通常所说的“无限授权”。

用户原本可能只想用 100 USDC 完成一次交易，却允许合约在未来动用自己地址中的全部 USDC。因此，只要该授权未被撤销，即便用户当时钱包中仅有少量资产，未来重新转入的 USDC 也可能受到影响。

其次，授权默认不会随着离开 DApp 而消失。很多用户会将“断开钱包连接”和“撤销授权”混为一谈，而实际上，断开连接只是让网页暂时无法读取或请求当前钱包，并不会改变已写入区块链的 Approval。

关闭网页、删除 DApp、清除浏览器缓存，甚至更换钱包应用，都不会使其自动失效。

最后，即使是正常的合约，未来也可能变得危险。因为许多授权风险并不只来自一开始是恶意的钓鱼网站，像此次的围猎，用户可能向一个当时正常的协议授予权限，但随后协议合约遭到攻击、管理员密钥泄露、可升级逻辑被替换，或者其调用的路由合约出现问题。

对于用户而言，资产仍然留在自己的地址中，但从权限角度看，另一个合约一直拥有调用这些资产的能力。因此，Approval 风险不仅仅是“我是否授权给了坏人”，还包括“我授权的对象未来是否会出现问题”。

面对 Approval 风险，最简单的建议是“不要无限授权”。

但在真实的 DeFi 使用环境中，完全拒绝授权并不现实，正如前文所述，授权本身并不是漏洞，它是链上应用调用资产的基础方式。

真正需要改变的是将 Approval 从一次性的确认动作，演变为一套持续的权限管理机制。

因此，对普通用户来说，首先需建立几个基本习惯：

当然，面对层出不穷的授权攻击，仅仅依靠用户的安全意识和定期检查并不足够，毕竟大多数用户很难辨别一串合约地址究竟属于谁，也难以判断某个授权额度是否合理。

来源：Odaily星球日报