什么是盲签(Blind Signing)？为什么绝不该签署你读不懂的内容

盲签(blind signing)是指批准一笔你的钱包无法以人类可读形式展示的交易或消息 —— 摆在你面前的是原始 calldata、一段不透明的十六进制数据，或一个 32 字节的裸哈希，而不是一句说明这次签名到底授权了什么的话。这不是密码学的失败：签名完全有效，在链上拥有完整效力，所以签署读不懂的数据，等于授予了你从未审查过的权限 —— 这也正是几乎每一款钱包盗币器赖以运作的基础。解药是清晰签名(clear signing)：钱包把请求解码成一句你能核对的话，并通过模拟预演哪些资产真的会转移 —— 再加上一个任何软件都无法替你养成的习惯：读不懂就拒绝。由于签名正是权限转移的那一刻，产生这枚签名的密钥是否只属于你，同样至关重要：WATS Hot Wallet 在 Ethereum、Arbitrum、Optimism、Base、Polygon、BNB Chain、Solana 和 TON 上都是非托管的，没有你亲自批准的签名，任何资产都不会动。

什么是盲签？

盲签指的是请求本身与它的显示内容脱节的任何一次批准。链会照着已签署的字节执行；而你的屏幕是唯一能把你的意图与实际内容作比对的地方。当屏幕上只有十六进制时，这种比对根本无从进行 —— 攻击者要的正是这份“无从进行”。

这道鸿沟属于信息层面，而非数学层面。签名并不编码“我同意兑换 100 USDC”，它编码的是“这把密钥授权这些字节”。这些字节究竟意味着一次兑换、一次无限额度授权，还是一张把你的 NFT 白送出去的链下订单，只有界面能够回答 —— 而界面拒绝回答的时候，盲签就发生了。

盲签会出现在哪些地方

盲签不是某一个功能，而是一整类“显示配不上数据”的情形。常见的几种：

请求类型	你通常看到什么	风险
eth_sign	一个原始哈希或十六进制数据块	极高 —— 设计上就无法验证；永远拒绝
原始类型化数据(EIP-712)	结构化字段 —— spender、金额、截止时间	含义不清时风险高 —— 字段可读不等于你读懂了
合约交易	一个已解码的动作；钱包解不出来时则是原始 calldata	完全取决于钱包的解码能力
只显示哈希的硬件屏幕	设备屏幕上只有一个哈希	高 —— 设备确认的是你在场，而不是你看懂了

四行的共同规律是：风险随可读性而变。渲染越单薄的地方，危险就越浓。

eth_sign 为什么如此危险？

在各种签名方法中，eth_sign 是这个问题最纯粹的形态：它要求你的钱包签署一个任意的 32 字节值，以原始十六进制显示给你，而且不带任何把消息标记为“只是一条消息”的前缀。由于输入没有域分隔，它可以是任何东西 —— 包括一笔把资产转出你账户的交易的哈希。仅凭弹窗内容，即便是谨慎的专家也无法核实这个请求；它在设计上就无法验证。这正是主流钱包已弃用或彻底移除该方法的原因，也是那条实践规则毫无例外的原因：截至 2026 年，一个仍在请求 eth_sign 的网站，要么危险地过时，要么心怀恶意，而这两个答案都指向拒绝。

硬件钱包到底给你看了什么？

硬件钱包把密钥保存在离线环境，并在恶意软件无法篡改的屏幕上显示请求 —— 但那块屏幕的价值，取决于它上面渲染出了什么。面对设备读不懂的合约交互，许多设备在历史上会退回到只显示一个哈希，而开启它的开关在设置里就直接叫 blind signing。在可信屏幕上确认一个哈希，只能证明你按了那个按钮，却证明不了你批准的是什么。硬件安全的承诺是所见即所签 —— 而当你所见的是三十二字节的噪声时，这个承诺就悄然瓦解了。硬件隔离保护的是密钥，不是决定。

盗币器如何利用盲签？

一套盗币器工具包，首先是一场针对签名体验的攻击。网站看上去像铸造页面、空投领取页或客服门户；它发出的请求则是一笔无限额度的代币授权、一个覆盖整个 NFT 收藏集的 setApprovalForAll，或者一条链下 Permit 或订单签名 —— 后者会在日后转走资产，而不再弹出任何提示。它们的共同点在于呈现方式：受害者签署了一个自己读不懂、或读了却没看懂的请求，随后资产就被掏空了。完整套路见什么是钱包盗币器，授权机制 —— 包括为什么一条免 gas 的签名就能清空一种代币的余额 —— 见代币授权与 Permit 详解。两者指向同一个根因：盗窃发生在签名那一刻，而盲签正是让攻击者能安然度过那一刻的东西。

什么是清晰签名 —— 它走到哪一步了？

行业给出的答案是清晰签名(clear signing) —— 即钱包必须先把每一个请求翻译成人能核实的表述，再去索要签名。截至 2026 年，它建立在两套机制之上。解码：钱包识别出被调用的合约与函数，把它渲染成一句话 —— 授权代币 X,spender 为 Y，额度无限 —— 而 ERC-7730 之类的努力正在建设开放的元数据注册表，让连硬件钱包的屏幕也能用人话显示合约调用，而不是一个哈希。模拟：钱包本身或它调用的服务，会在你签名之前把交易放到当前链状态上跑一遍，预览结果 —— 哪些资产会离开、哪些会进来、哪些授权会变化。模拟是预测而非保证 —— 预览与上链之间状态可能变化，恶意合约上链之后也可能表现得不一样 —— 但一份显示你的 NFT 正流向陌生地址的预览，足以叫停绝大多数盗币。截至 2026 年，各钱包与各条链的落地程度仍不均衡，所以在指望它替你示警之前，先看看你自己的钱包在一次日常操作中究竟渲染出了什么。

实用规则：读不懂就当作不可信

为了安全，你并不需要会读 calldata —— 你需要的是让读不懂的请求默认失败的习惯：

• 永远不要批准 eth_sign 请求。它已经没有任何正当的主流用途 —— 这个请求本身就是危险信号。
• 优先选择会解码、会模拟的钱包。如果你的钱包在一次日常操作上就只显示原始十六进制，那是值得为此换掉它的钱包问题。
• 读懂那些真正要紧的字段：类型化数据请求里的 spender、金额、截止时间、operator。无限额度或陌生的 spender，就是停止信号。
• 让硬件钱包的盲签模式保持关闭，除非你完全清楚某一笔特定交易为什么需要它 —— 用完之后立刻关回去。
• 连接要慎重。大多数恶意请求都是通过匆忙的连接进门的 —— 如何安全地把钱包连接到 dApp 里的那套流程能守住前门。
• 读不懂等于不可信。拒绝一次签名，代价不过是重来一次；签错一次，代价可能是全部。这种不对称已经替你做好了决定。

WATS 处在什么位置

盲签是一个显示问题。解码与模拟能把请求呈现成可读的表述，但没有任何钱包 —— 包括 WATS —— 能替你判断这个请求是不是你真正想要的。钱包真正能决定的，是谁掌控着那把把决定变成权限的密钥。WATS Hot Wallet 是完全非托管的：密钥由你持有，WATS 从不持有任何密钥，在 Ethereum、Arbitrum、Optimism、Base、Polygon、BNB Chain、Solana 或 TON 上，没有你批准的签名，任何转账都不会离开你的账户。这砍掉了一整类风险 —— 没人能代替你签名 —— 同时把上面那套阅读纪律，原封不动地留给你自己。

WATS NFC Metal Card 站在同样诚实的位置。它不存储私钥，也不解码 calldata：它是一张点触验证设备，拥有唯一的卡片 ID，只与一台设备配对，用来对存放在 WATS 应用中的密钥进行验证。这增加了一个实体要素 —— 一件你握在手里的东西，而不只是屏幕上的内容 —— 但它无法把读不懂的请求变得可读。除了弹窗本身，没有任何东西能做到这一点。

所以请把这两半分开来看。阅读的那一半是习惯：读不懂就绝不签名，凡是以裸十六进制形式送到眼前的，一律拒绝。托管的那一半是一次性的选择：把密钥放在非托管钱包里，让签名权留在它该在的地方。安装 WATS Hot Wallet，把每一个读不懂的弹窗都变成自动拒绝；如果你想要一个实体要素来验证你对 WATS 应用中那些密钥的访问，就把一张 WATS NFC Metal Card 与你的设备配对。