北京
问你一个问题：当你点下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.
