问你一个问题:当你点下MetaMask的「确认」按钮时,钱包到底看到了什么才敢放你过去?
很多时候它什么都没看到。这就是那个无聊却致命的设计失误——用户在钱包提示弹出来之前,既不知道请求的路径,不知道这笔操作会打给哪个智能合约地址,也不知道授权额度到底是多少。产品还没把调用来源、消耗方、链和审批范围串起来,就直接把屏幕最危险的那个「签」字丢给你了。
![]()
安全圈一直有一个略显单薄的论调:大语言模型能让钓鱼诱饵更便宜、更像那么回事。这话没错。Google Cloud的《网络安全预测2026》把AI驱动的社工攻击列入了威胁上下文,Chainalysis的2026诈骗报告也把冒充诈骗和AI辅助诈骗当成了方法论层面的重大变量。但所有这些研究指向的都是同一个窄结论——语言模型能把鱼钩捏得更逼真,却还没人认真想过,真正该在钱包里拦住这根鱼钩的,不应该是模型,而是钱包自己。
坏掉的提示长什么样
一个失败的提示并不是「用户看到一个吓人的消息」。而是「在用户确认之前,钱包竟然说不出发起源是哪个域、目标链是哪条、接收方是谁、授权额度是多少、截止时间到哪天、风险警报到底因为什么」。Web3盲签名攻击的研究已经反复证明,用户在签名时根本没有能力去审查消息到底授权了什么东西。这个前签名风险包的设计,就是把这种审查盲区,变成产品可以逐字段检查的硬标准。
这个设计不是恐慌的产物,是对操作临近性的冷静回应。在用户的整个交互流程中,一条危险的链下调用路径可以紧紧贴着EIP-712类型化数据签名、代币批准、Permit2授权或WalletConnect会话请求出现。这些高风险动作和普通操作在界面上的距离,近到你根本意识不到它们的本质差异。所以我们要把安全判断从「通用确认弹窗的一串十六进制字符」里拽出来,放回到一个结构化的、可以逐行读懂的字段集合中。
模型只负责递证据
在这里,语言模型只被分配了一个极其狭窄的活儿。它可以标记可疑的请求来源,识别高仿域名,发现抄来改去的品牌文案,或者捕捉那种莫名其妙的紧迫感。模型给出的评分,唯一合理的用途是向钱包解释「为什么要让这次签名流程慢下来」。但这个评分绝对无权批准一个收款地址,无权悄悄压下一则警告,也无权放宽支出限额。签名流程到底能不能继续往下走,必须由一套完全不受模型干扰的确定性规则来决定。
这个分工乍看反直觉:明明用AI来检测诈骗,为什么不顺便让AI帮你拍板?原因很简单——让你被骗的语言技巧,和让你放行的语言模型,共享同一套底层能力。一旦把审批权交给它,就等于给钓鱼者递了一把能绕过所有按钮的万能钥匙。把模型控制在证据车道的做法,本质上是利用它的模式识别能力,同时锁死它作恶的可能。安全这事,不能靠猜,只能靠死规矩。
看一眼到底该看哪些字段
拆解这个包的设计思路,最能抓住本质的方式是一张「字段地图」。从钱包已经暴露或可以轻松解码的数据开始,EIP-712带来了类型化结构化数据和域分离字段。它同时明确指出,重放保护不是EIP-712自己就能提供的东西。以太坊登录标准Sign-In with Ethereum则给了一个绝佳的示范:域名、URI、链ID、防重放随机数、签发时间和请求来源检查,这六个字段才是产品安全决策真正的食材,不是围在通用确认框周围的那圈装饰花纹。
授权相关的字段更值得单拎出来放大看。ERC-20标准定义了批准、允许额度、消耗方和转移函数;ERC-2612在此基础上加了签名许可,把拥有者、消耗方、价值、随机数和截止时间带进了签名流程;再到Permit2,一次性签名转账和额度转账被彻底分开,AllowanceTransfer的参考文档里把最大额度行为写得明明白白。在用户把手指伸向签名键之前,产品必须能把请求的权限直接归进四个透明格子里:一次性、有限额上限、有时间窗口限制,或者接近上不封顶的额度。这个分类做不出来,用户就是在闭着眼睛签空白支票。
这套前签名数据包的逻辑,其实和你出门前检查钥匙、手机、钱包是一样的——它不是要吓唬你外面多危险,而是让你在把手伸出门把手的同一刻,清清楚楚地把该确认的东西确认掉。当你的钱包不再靠一句「请确认交易」蒙混过关,而是把域名、链、对象、金额和时间一条条挡在你和可能出现的恶意合约之间时,钓鱼就不再是一场凭运气的概率游戏,而是一道你能自己验算的算术题。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.