用一次免 Gas 兑换，钱包可能连弹三到四次签名窗：先签一份花费授权（Permit 一类），再签订单、再签履约指令。每一弹都得重新读一遍域和参数，用户对”我到底批准了哪几件事”的记忆越来越模糊。ERC-7920 提出的复合签名试图把这一段体验改写：多条 EIP-712 类型化消息编进一棵默克尔树，用户只对树根签一次，各条消息仍能被独立验证。该提案目前是 Draft（草案）状态，本文按提案文本解释机制，现状与风险都在文末摆清楚。
机制：把 N 条消息哈希折进一棵树
规范步骤很薄。第一步，对一组消息逐条做 EIP-712 的 encode 并取 keccak256，得到每份消息的哈希；第二步，把这些哈希当叶子节点构造默克尔树，算出 merkleRoot；第三步，只对树根签名。验证某条单独消息时，验证方拿这条消息重算叶子哈希，沿默克尔路径爬回树根，再验根上的签名——不需要看见其他消息的内容。于是三件原本互相拉扯的目标被同时摆上桌：一次签名覆盖整批、每条消息可脱离批次单独验证、以及 EIP-712 的可读性被保留（叶子仍是标准类型化消息，钱包可以逐条渲染给用户看）。这第三种属性是它区别于”把一堆参数拼成一条巨型消息”式合并方案的关键：合并成一条的写法里，拆开任何一条都没法自证属于那一批，复合签名的树结构天然支持拆包验证。
它填的是什么坑
提案的动机部分列了三种现有做法的缺陷，读起来像一份用户体验事故清单。预先发一笔 ERC-20 授权额度：省事但把持续动币的权力交了出去，属于安全换便利。合并成单条消息：一次签完但牺牲独立验证性。逐条分别签：安全边界最清楚，但每次弹窗都是一次真实的注意力消耗，用户到第三条往往已经不看了。而且弹窗数量本身在制造歧义——批与批之间的消息彼此没有绑定，用户其实无法确认”我签过的几条凑不凑得成这个应用声称的那一套”。复合签名把绑定关系写进了密码学结构：规范还允许验证方要求”消息 x 必须与消息 y 同批出现才算数”这类组合条件，这是逐条签名做不到的。
用户视角的纪律：签一次，等于批一整摞
对普通持有人，复合签名带来的最重要的行为约定只有一句：把批量当批量看。过去一次弹窗对应一条消息，核对弹窗即可；树根签名下，一次弹窗可能代表五条消息的集合，若钱包只显示”根哈希已签名”而不展开逐条内容，用户的知情程度就退化了。因此钱包侧的展示质量成了这套方案安全性的实质环节——与 钱包弹出的结构化签名窗口：域名信息四行到底在防什么 讲的弹窗阅读是同一门课，只是考题从”读懂一条”升级成”读完一摞”。操作纪律可以总结为：先要求界面展开每条消息的对象、额度、过期时间四件套再签；展开不出来的批量请求，默认拒签；签后想清点，去授权管理页逐条确认（链下签名的记录与链上交易的区别见 签名不花 Gas，但不等于免费：链下签名与链上交易的安全边界）。
草案阶段的正确姿势
Draft 意味着规范措辞仍可能变，也意味着没有义务被任何钱包或协议实现。今天你在某个应用里遇到的”一次签多条”，更可能是各家自研的合并方案而非本标准的落地——判断方法很简单：看应用文档是否写明遵循 ERC-7920，没写就用它自己的措辞理解风险。对安全敏感的用户可以把提案当成一个提醒：无论打包技术怎么变，签名确认权是不可外包的环节，任何把多条请求压成一键的操作，都应该同时给你无损展开每条的能力。
本文为机制科普，提案状态以官方页面当前显示为准；不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。