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