签名前先看清人话：ERC-7730 可读签名格式

“签这笔之前，请确认你理解你要签的东西”——绝大多数钱包弹窗做不到这句话，因为一笔调用的原始数据是几十行十六进制，翻译成人话依赖各家钱包自己维护的合约知识库，永远滞后、永远缺漏。ERC-7730（Structured Data Clear Signing Format）想用一份标准 JSON 格式弥合这道缝：让数据本身带上”怎么给人看”的说明书。该提案状态为 Draft（草案），创建于 2024 年 2 月 7 日。本文讲机制，不构成任何操作建议。

说明书长什么样

规范的输出是一份 JSON 描述文件。context 段把说明书钉在具体的合约部署上：以约束的形式列出各链的部署地址，钱包必须先核对当前待签数据命中这些地址，才允许套用格式化信息——这一段防的就是”说明书张冠李戴”。metadata 段声明说明文件的作者、合约名与信息链接，出处公开可查。display.formats 段按函数签名逐个定义展示方式：intent 给出动作摘要（比如 Send），interpolatedIntent 是带占位符的人话模板（如 Send {value} to {to}），fields 数组再为每个参数指定标签与格式——代币金额要用 tokenAmount 格式并指明从哪个路径取代币合约地址，才能把最小单位换算成可读数量。规范的预期是应用开发者写一次这份文件，各家支持标准的钱包都能复用。规范也坦承边界：这套格式当前面向合约调用与类型化数据，ERC-4337 的 UserOperation、批量调用等更复杂的载荷留待未来扩展。

它针对的是盲签与钓鱼

盲签（对着哈希直接签名）之所以危险，是因为签的人不知道哈希背后是什么。可读签名的防线在于：把字段含义与交易结构在签名前摊开，钓鱼交易最怕的正是”被看懂”。但标准改不了信任来源——说明书若由对手合约自己提供，恶意合约也可以写一份体面的假说明。规范对此的处理是把出处写进 metadata、把适用地址钉进 context，由钱包先验证约束再展示说明，也就是说，它把”谁写的说明、适用于哪个合约”变成了可审计的信息，而不是直接消灭造假。

现实里的使用姿态

1. 钱包支持 clear signing 且交易带说明时，逐字段核对展示内容而不是只看摘要行，重点看金额、合约、有效期与被授权方。
2. 对无说明的乱码交易维持最高警惕：能换支持可读预览的接口就换，不能换就把链上原始数据与官方文档逐项对照。
3. 阅读说明也别忘了对照链：说明文本提到哪条链、当前弹窗是哪条链，错配是老钓鱼手法。
4. 记住任何说明书的标准状态（Draft）意味着生态覆盖率参差不齐，“钱包显示人话”与”交易安全”是两件事。

谁会先支持、先受益

从动机看，这类格式文件最该最先覆盖的是高频、标准化的调用：ERC-20 的转账与授权、ERC-721 的授权与挂单——参数结构固定、语义直白，一份文件能吃掉绝大多数弹窗。NFT 场景里最典型的收益点是市场挂单签名：涉及代币合约、市场合约与中间转账通道三层地址，普通用户几乎不可能逐段核对，可读预览把”被授权花你 NFT 的通道合约”这类关键字段直接端上来。反过来说，结构冷门的自定义合约在文件普及前仍将长期停留在乱码弹窗阶段——这也是为什么对新协议的第一笔交互，读源码或等社区逆向报告仍是绕不开的动作。

可读签名是签名卫生的升级件而非银弹：人话预览加人工核对，仍比任何单点自动翻译可靠。本文仅为机制科普与防御提示，不构成投资建议。