ERC-6384 可读签名：让合约自己告诉你这笔签名要干什么

你签的到底是什么

EIP-712 让签名从“一串看不懂的字节”进步到“有结构的字段”，但体验上的缺口仍在：钱包弹窗遇到复杂类型常常只显示哈希；“你授权 0x 前缀加一串十六进制的角色”这类字段，普通人完全无法判断后果。签名钓鱼因此长期存在——同一份结构数据，换个字段值就可能从“领空投”变成“委托投票”。

ERC-6384 提出了一个直接的想法：合约既然设计了这份签名数据，就应该能自己解释它。标准引入一个函数 evalEIP712Buffer：把一笔 EIP-712 数据缓冲区交给合约，合约返回一句人可读的描述，例如“把tokenId 42 的投票权委托给地址 0x …”。钱包在弹窗前调用它，把自然语言直接铺在用户眼前。

现状：一份停滞的提案

必须先讲状态，因为它决定你今天的防护手段。ERC-6384 在标准仓库中的状态是 Stagnant（停滞）——草案或评审阶段长期不活跃的标准会被移入这个状态，理论上作者或编辑可以复活它，但现实是几乎没有主流钱包支持调用这个函数，绝大多数合约也没有实现它。读这篇的目的是理解思路，而不是误以为签名安全已经解决。

为什么推行困难？三个现实原因：一是责任问题——“合约写的描述”本身可以被项目方写得轻描淡写，甚至与真实行为不一致，钱包采信描述反而可能给用户虚假安全感；二是调用成本与延迟，每次签名请求多一次链上查询；三是恶意合约完全可以不实现或乱实现，标准无法强制诚实。

停滞不等于无用：可行的读法

这个思路的合理内核是“交叉核对”。即便没有 6384，你今天就能用类似逻辑提高安全性：

1. 同一笔签名，看结构字段而不是看哈希。很多钓鱼签名复用热门协议的字段名，但数值异常：过期时间设在未来十年、verifyingContract 是陌生地址、nonce 为固定值。
2. 用独立来源复现含义。交易构造类工具可以把结构数据还原成可读文本，再与钱包弹窗对照——两边不一致的那一处，往往就是陷阱所在。
3. 记住“描述可能说谎”。任何来源的描述（项目文档、钱包提示、合约返回）都只是线索，结论要从字段值本身推出来。

对普通用户的防御清单

在可读签名标准真正普及之前，可执行的防御仍然是分层的老几样：用支持 EIP-712 字段级展示并能显示 domain 信息的钱包；对反复交互的协议把签名请求存档做对比；不理解的签名先在区块浏览器和安全工具里试解析，确认无异常再签；定期审视链上已签授权并撤销不再使用的部分。

从研究视角看，ERC-6384 的价值不在那个函数，而在它提出的问题：签名 UX 的解释权应该由谁掌握。让合约自报家门简洁优雅，但解释必须可被证伪——这也是后来各类模拟与形式化检查工具走的路。两条路线并不互斥，未来的钱包大概率是“合约描述加外部模拟”双通道并行，任何单一信源都不被单独信任。在这个未来到来之前，标准号本身帮不了你，检查字段的习惯可以。

风险提示：离线签名可能被用于授权敏感操作，遇到无法理解的签名请求应拒绝；本文仅提供防御性安全说明，不构成任何投资建议。