MEV是如何抢走你的空投的？ AI 写的代码交给 AI 审核弄丢了 AI 撸的空投？ 别笑，这不是一个段子 @tokentable 给 @AIWayfinder + @KaitoAI 空投写的合约，有趣的地方我扒一点出来，不懂代码也能看 让我们潜入！ ⬇️ * 注，本文仅讨论代码和逻辑，不涉及其他推断，如有错误，欢迎指正。 1️⃣ 发生了什么？ 用户在 @KaitoAI 领取 @AIWayfinder 发放的空投 PROMPT 时发现币不见了。 我第一时间发了预警，给kaito提供空投合约的 @tokentable （ @sign 旗下）随后也证实了，合约有问题导致被mev抢了 我在 @okxchinese builder 群也第一时间反馈，有人质疑我在搞笑，原因是他在领取的时候开启了mev防护，怎么会被抢？ 真相在代码里。 2️⃣ 神奇代码之错误百出 function __endaddress_to, uint256_amount, uint32_clainId) internal { if (clainId == block.chainId) { recurrency.value == 0, UnnecessaryFee(); TOKEN.safeTransfer(to, amount); 先不说代码功能了，chainId、clainId、claimId傻傻分不清，这种错误出现在这里也是罕见的。recurrency.value == 0语法也错了，神奇的是，检查gas功能失效，但并不影响主程序跑起来…… 你说这是AI写的，肯定是在侮辱AI，但是你说不是吧… function __send(address_to, uint256_amount, uint32_clainId) internal { if (clainId == block.chainId) { require(msg.value == 0, UnnecessaryFee()); TOKEN.safeTransfer(to, amount); }} constructor(ERC20 tokenAddress) { // If you want it truly "hardcoded," you can directly assign: // TOKEN = IERC20(0x1234567890123456789012345678901234567890); // But for easier testing, we'll pass it in as a constructor argument: 这AI写代码的招牌套路和注释都还没删掉…… @notice、@param ERC20变成了IERC20……再加上硬编码的牛逼建议注释，兄弟，这里最好删掉，老板看不懂代码，英文还是可以看懂的吧？ 关键是兄弟真是听进去了AI 的话，直接把管理员角色被硬编码授予了一个特定地址，是一个多签地址。 3️⃣ 币也没了，Gas还挺贵？ 有人也反映了，tokentable领取空投3u打底的gas还挺贵，一开始我也没注意，但昨天这个事，再看看合约代码，有趣了。 function addClaimable( address[] calldata recipients, uint256[] calldata amounts, uint256 nonce ) external onlyRole(FUNDER_ROLE) 我的强迫症要犯了，caldata 又是什么鬼东西？这也能行，哥们Solidity 编译器版本还是 0.4.x？算了，不纠结了，代码能跑就行。 也许其他地方人家有特殊的定义，特殊的编码爱好。 这里要说的是，这位兄弟，把所有空投信息直接存储接收者和金额的数组，用的mapping，并没有使用默克尔树。 不懂代码也没事，简单理解就是用mapping 项目方在链上会消耗大量gas，尤其是大规模空投时，但用户领取的gas便宜，只需要一个claim就行。 使用默克尔树，项目方只需要一个root，用户领取的时候需要验证，gas稍贵。 良心项目啊！可为什么用户领取的时候却还需要3u以上的gas呢？ 这，是不是一个好问题？ 4️⃣ MEV是如何抢走你的币的？ 我开了防MEV啊，在搞抽象？你的MEV是开了，但你地址被替换了。这什么意思？举个例子。 骑手取外卖，商家只听谁喊得快，一份A骑手的外卖尾号8888，当外卖做好后，商家按铃可以取餐。 ▰ 此时A骑手低头还在看自己尾号 ▰ B骑手大声高喊，8888在这里 ▰ 商家把外卖给了B骑手 商家没有验证骑手尾号。这份合约里，任何人都可以传递任何地址的声明数据，但代币总是发送给msg.sender而不是声明数据中指定的地址。 ▰ mev 监控内存池，等用户点claim ▰ 将to参数替换为自己的地址 ▰ 保持相同的金额和其他验证数据 ▰ 加速，完成攻击 缺少接收者地址验证，这就是为什么mev开了也被抢走，因为比起抢跑，把你地址给换了，更致命。 5️⃣ 攻击者是如何发现漏洞的？ 这也是个好问题，谁那么牛逼可以在那么短时间发现漏洞并神奇写好代码狙击？ 天下没有新鲜事，搜索这个合约近似代码，可以发现之前部署了测试合约，也许就是这份测试合约的漏洞，被发现了。 合约的部署者，有一个还关注了我，我就不暴名字了，提供地址如下，有兴趣可以挖掘一下： https://etherscan.io/find-similar-contracts?a=0x1A8B3BDC38566DF28b0B4e65DC28aF2069EB0645&m=exact 这里要说明一下，未经审计的合约测试暴露在公共领域，也是危险的，这里并没有直接证据说测试者和mev有关，仅作为一种可能推测。 即，攻击者从sigh之前的空投合约里（正式或测试）里已经发现了漏洞。 6️⃣ 没有审计？如何收场？ 这不属于我讨论的范畴，是否有审计、哪家审计需要tokentable来披露。 @realyanxin 已经说了会赔付，连差价也会赔。有这句话就够了，足够有格局。 但……一直以高科技、高收入著称的sign出现了这样低级技术问题，也许需要给社区一个说法？或在内部，无论在人才还是流程上，需要好好管理一下。 当然，我也不在社区，可以无所鸟谓，不用搭理我。 7️⃣ 一点小建议 对普通用户来说，推荐使用 OKX wallet @wallet ，在进行交易、领取空投记得打开 「防MEV」功能。 这几乎可以保护你大部分的交易不被攻击，但有时候，如果合约出了问题，那就不是钱包能保护得了你的了。 * 最终结果请跟踪、参考 @tokentable 官方说明，本文不构成任何投资建议。