EIP-712 的结构化签名你已经不陌生：弹窗里那几行域名信息，作用是把签名钉死在”哪条链、哪个合约”上，详见一串交易十六进制怎么读：类型字节、字段顺序与签名尾巴的位置的字段拆法。ERC-7803 草案想在这套机制上补两块，都面向智能账户：一是签名域（signingDomains），把签名进一步钉到”哪个账户”；二是认证方式（authMethods），让应用提前说清楚它会用哪种方法验签。两项都是 eth_signTypedData 请求上的可选字段。提案标注为草案。
签名域：一把钥匙开多把锁时的防重放
问题从密钥与账户不再一一对应开始。一个助记词或一枚硬件钱包密钥可以控制多个智能账户，ERC-1271、ERC-6492 这类标准让合约账户也能出签名，但签名如果只绑定应用合约，就可能被拿在这个账户签过的内容上复用——同一枚签名换到兄弟账户再放一遍，就是跨账户重放。EIP-712 原有的”验证域”负责钉住验签的协议合约，想把账户也钉进去，实现上会撞上复杂度与账户可组合性（智能账户控制智能账户）的未解问题，ERC-7739 就是前车之鉴。ERC-7803 的做法是新增一层”签名域”：编码时把签名域的哈希数组按顺序前置进摘要，形成递归结构。规范给的例子很直观：多签给签名人发请求，先把自己账户的域压进列表；签名人用的是硬件密钥管理的智能账户，钱包再把该账户域压进去——列表长度一层层加，每一层对应链条上的一个账户。
认证方式：先说清楚”我会怎么验”
另一半问题在验证侧。ERC-1271 让合约自己回答 isValidSignature，很成功但很宽松：有的合约先试 ECRECOVER 再问合约，有的反过来，同一枚签名两种顺序下结果可能不同——EIP-7702 之后这种分歧会更扎眼。ERC-7803 允许应用在发起签名请求时用 authMethods 声明自己将使用哪些认证方法、按什么顺序。钱包据此知道自己该产出什么形态的签名；反过来说，规范明确：请求里没有 authMethods 时，返回的签名要当作不透明字节处理，别自作聪明猜格式。
用户视角：弹窗多了字段，纪律没有变
普通用户什么时候会碰到它？大概率是钱包或登录组件底层升级后，某些站点登录、下单的签名弹窗内部结构变了而外观没变。可执行的核对动作仍是老三样：确认发起站点域名、确认链号、确认内容里有没有有效期与nonce类字段。真正新增的判断只有一条——如果同一枚密钥管着多个账户，签名请求理论上应带上账户绑定信息；若你在多账户场景下遇到”一个站签完另一个站也能用”的可疑迹象，那就是重放防护没做足的场景，先停手。链绑定的老底子见同一句助记词，三条链的地址为什么完全不同？币种段与地址格式，跨链同一句助记词地址各异的原理同样适用于”同一密钥多个账户”的直觉建立。
一次典型请求的内部旅程
把两块新字段放进一次登录签名里走一遍：站点调 eth_signTypedData，请求里带 typed data 本体、空的或一层 signingDomains、authMethods 列出”先 ECRECOVER、再 ERC-1271”两个方法与顺序。你的钱包若只是普通账户，走常规 EIP-712 编码返回签名；若你是多签成员，多签客户端会把自己账户域压进 signingDomains 再转给你；你按编码规则出签名后，站点按自己声明的顺序验——先试直接恢复地址，失败再调用你账户合约的 isValidSignature。整个过程没有任何上链动作，gas 为零。链条里每一跳的域哈希都必须由参与方在设备上重算一致，任何一跳被中间人改写字段，最终摘要就对不上——这正是把”域”做成数组而不是单个字段的原因：账户可以套账户，链条长度天然可变。
边界说明
两点别越过。其一，本提案是草案，字段全部可选，现网大多数签名请求不带这两个字段，账户实现也各走 ERC-1271、ERC-6492 等既有路线，不存在”没带 signingDomains 的签名就无效”的结论。其二，它不改变签名免费这个事实，也不改变一条通道完成连接：ERC-7846 的 wallet_connect 把授权与登录合成一次弹窗这类连接类提案的授权流程，只是给 typed data 请求加料。评估它值得盯的信号是钱包与主流验签合约的支持面，而不是提案页本身的措辞。
风险提示：链下签名不花 gas 但可能被复用，涉及资产操作的签名请先核对链号、域名与有效期，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。