撰文：imToken
一个长期在以太坊上猎取普通交易者的 MEV 机器人，最终也掉进了一个价值 750 万美元的「定制版」陷阱。
6 月 21 日，以太坊上知名的三明治套利机器人 Jaredfromsubway.eth 遭到攻击，地址内的 WETH、USDC 等资产被转走，初步统计损失超 750 万美元（不过目前公开披露的损失口径仍有差异）。
有意思的是，这次攻击既不是私钥泄露，也没有利用传统意义上的智能合约漏洞，而是攻击者提前部署大量虚假代币、流动性池和辅助合约，将其包装成可能存在套利空间的交易路径，诱导机器人在自动化执行过程中，向恶意合约授予了 ERC-20 的 Approval，最终「合法」转走了该 MEV 机器人的资产。
截止发文时，Jaredfromsubway.eth 已通过链上消息向攻击者公开喊话，表示「若在 48 小时内归还 2150 枚以太坊，愿意支付五成白帽赏金，否则将采取一切可行的法律及执法手段追责」。
不过，连高度专业化代码驱动的 MEV 机器人，都会在 Approval 上栽跟头，也不禁让人重新审视，这个我们每天都在使用的「Approval」动作，究竟隐藏着多大的危险？
一、一场专为 MEV 机器人设计的反向围猎
如果认真复盘这次攻击事件，就会发现这并不是一次偶然触发的漏洞，而是一场针对 Jaredfromsubway.eth 交易逻辑设计的长期围猎。
Jaredfromsubway.eth 一直是以太坊上最知名的三明治套利机器人之一。所谓三明治攻击，简单来说，就是机器人发现一笔即将发生的链上交易后，抢先在用户之前买入，推动价格上涨；等用户以更差的价格完成交易，再立即卖出，从中赚取价差。
也正因如此，该策略要求机器人持续扫描链上交易，以极快速度判断套利机会，并组织交易路径，去调用不同的代币和合约，这也意味着速度越快、覆盖的资产与协议越多，机器人能够捕捉的机会也就越多。
但正是这一点，成为了这次事件的突破口。
根据事后复盘，攻击者并没有直接攻击机器人的资金合约，而是花费了数周时间，构造一组看起来能够盈利的交易环境：
- 第一步，是部署大量虚假代币与流动性池。这些代币在名称、接口和交易行为上模仿 WETH、USDC、USDT 等常见资产，让机器人的自动识别系统误以为发现了正常交易路径；
- 第二步，是逐渐获取机器人的信任。在早期测试中，机器人授予的授权随着交易正常使用，等到机器人的系统开始重复执行类似路径后，攻击者再调整合约逻辑，让机器人产生的部分授权不再被实际消耗，也没有在交易结束后归零，导致这些授权就这样留了下来；
- 最后，攻击者集中调用仍然有效的授权限额，将机器人合约里的真实 WETH、USDC 和 USDT 转出；
说白了，整套攻击完全瞄准了 MEV 机器人的运行特点，即先制造一个符合其盈利判断规则的环境，再利用其追求自动执行交易路径的机制，让系统主动交出资产调用权。
这也解释了为什么连高度专业化的 MEV 机器人都会中招。
它懂得如何计算价差、Gas 成本和交易顺序，却未必会对每一个新出现的合约进行充分的身份验证，从这个角度说，普通用户的问题是「没有看懂就点了确认」，自动化机器人的问题则是「没有确认就自动执行」。
表面上看，两者完全不同，底层风险却很接近，因为他们都把授权当成了完成交易之前的一个普通步骤，而没有清晰意识到它潜藏的风险有多高。
二、Approval 为什么总是被低估？
众所周知，在以太坊及 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 风险
面对 Approval 风险，最简单的建议就是「不要无限授权」。
但在真实的 DeFi 使用环境里，完全拒绝授权并不现实，正如上文所述，授权本身并不是漏洞，它是链上应用调用资产的基础方式。
真正需要改变的，是将 Approval 从一次性的确认动作，变成一套持续的权限管理机制。
那对于普通用户来说，首先需要建立几个基本习惯：
- 第一，遵循「最小权限」原则。在钱包弹出授权提示时，尽量根据本次交互的实际需要设置额度，比如只准备使用 100 USDT，就尽可能只授权接近 100 USDT 的额度，而不是直接开放无限权限；
- 第二，区分储存钱包和交互钱包。长期储存大额资产的地址，尽量不要频繁连接陌生 DApp；参与空投、Mint、新项目和高风险 DeFi 交互时，可以使用单独的地址，将潜在损失限制在较小范围内；
- 第三，定期检查并撤销不再需要的授权。用户可以通过 Revoke.cash 等工具，或在 imToken 中进入对应代币页面，点击左下角「Token Function」，再选择「授权管理」，查看该地址的授权对象、代币和额度，并对不再使用或来源不明的权限发起撤销（延伸阅读《手把手教你使用 Revoke.cash 进行授权管理》）；
当然，说一千道一万，面对防不胜防的授权攻击，仅仅依靠用户的安全意识和定期检查还是不够的，毕竟大多数用户很难分辨一串合约地址究竟属于谁，也很难判断某个授权额度是否合理。
那作为用户进入 Web3 的第一道护城河，钱包必须在产品能力上提供主动防御。
以 imToken 为例，就会对已识别的风险代币、地址和 DApp 进行标记或拦截，当用户向普通外部账户授予代币权限，或者向合约地址直接转账时，也会提供针对性的风险提示，这些提示无法替代用户判断，但至少可以在真正签名之前，增加一道必要的安全缓冲。
除此之外，imToken 还在 DApp 登录、转账、代币兑换与授权等关键环节，对签名内容进行结构化解析与可读化呈现，尽可能帮助用户在确认之前理解自己正在同意什么，确保用户签署的内容，必须与其所看到的行为保持一致，而不是被压缩成一段难以辨识的哈希数据。
随着 ERC-7730 等 Clear Signing 标准进一步推进，这种「所见即所签（What You See Is What You Sign）」的可读化展示，也有望从单个钱包的产品能力，逐渐成为钱包、DApp 和智能合约之间共享的行业标准。
总的来看，私钥决定谁拥有账户，Approval 决定谁还能调用账户里的资产，两者并不是一回事，却同样重要。
这也意味着，钱包安全不能只停留在「私钥有没有泄露」，而且这需要从用户到钱包，大家共同努力：对用户来说，需要在授权前看清对象和额度，在交互结束后及时清理不再需要的权限；对钱包来说，则需要让这些原本隐藏在合约里的权限变得更可见、更容易理解，也更方便被限制和撤销。
毕竟，真正危险的未必是刚刚发生的那笔转账，也可能是一个早已被遗忘、却始终没有失效的授权。
