ERC-7964 跨链 EIP-712 签名：一份签名怎么只在该用的那条链上有效

EIP-712 签名的域分隔符里可以带 chainId，这条防线在单链场景基本够用。但跨链场景很快暴露缝隙：一份为链 A 设计的签名，如果其结构恰好被链 B 上的合约同样接受，就会发生跨链重放；反过来，用户想在一次签字里授权多条链上的一组操作，标准做法只能签多份。ERC-7964 试图把跨链要素写进签名规范本身：用 ChainOperation 数组显式声明每条链和该链上的操作哈希，验证函数把整个数组折进摘要。按照以太坊 ercs 仓库的记录，这份提案名为 Crosschain EIP-712 Signatures，状态为 Draft，创建于 2025 年 6 月 5 日。

从单链签名到链数组

编码的核心是一个操作数组：每个元素包含目标链的标识与该链上业务数据的结构哈希。签名时，合约对整棵结构（包括每条链的标识）做类型化哈希，得到唯一摘要；executeIntent 执行时，各链上的接收合约调用 isValidCrossChainSignatureNow 之类的验证入口，把自己所在的链放进重建路径——签名在错误的链上验证时，重建出的摘要必然不同，验证失败。提案同时给出 parseCrossChainSignature 供钱包在签字前把数组展开成人能读的清单：哪条链、哪类操作，逐项列清再签。与直接在域里塞一个 chainId 相比，数组形态解决的是同时授权多链、每链语义不同的情况。

钱包显示是规范的一部分

标准文本专门有一节讲 Wallet Display：跨链签名的风险一半在用户看不签的到底是什么。提案要求钱包把 ChainOperation 数组渲染成带链名称的分项视图，而不是一坨十六进制。这一节的现实意义可以从历史事故里找对照：签名类钓鱼最常见的成功路径，就是让域字段指向仿冒合约、让用户在摘要不透明时按下确认。把链维度做成可见、可核对的显式字段，等于把防钓鱼的工作从用户眼力转移到钱包渲染。

它替代不了什么

先把边界说清。ERC-7964 管的是签名语义层——一份凭据在哪些链、哪些合约上数学上有效；它不搬运任何资产，消息真正抵达另一条链仍要靠桥、预言机或意图网络这些执行基础设施。它也管不住验证合约的实现缺陷：如果链 B 上的合约在重建摘要时偷懒没把自身 chainId 折进去，规范写得再好也会翻车。因此对使用方，检查点反而更明确了：凡自称支持跨链签名的合约，都要能回答一个问题——在别的链上用同样字节重放这份签名，验证会不会失败？答案应当能在源码里找到对应逻辑。

与相关标准的关系

签名字段全部来自标准结构这一事实，也给了工具层新的检查面。安全软件可以在交易模拟之外多做一步：把待签对象里的链数组与用户当前操作上下文比对——你明明在链 A 上领 NFT，签名里却列着链 B 和链 C 的操作条目，这类上下文错位正是钓鱼脚本爱钻的缝。规范本身不强制钱包做这种联想校验，但它使这种校验第一次成为可能：信息都在签名结构里，不看是工具的失职。用户层能做的等价动作同样朴素：签字前把弹窗里的链标识逐个念出声，与自己此刻意图逐条对上；对不上的那一项，就是这笔签名的全部风险所在。跨链签名不是更高级的签名，只是把多链授权的不透明性摊开在明处——摊开了，检查责任也正式回到人这边。

它不取代 EIP-712，而是给 EIP-712 补一段跨链结构定义；与单链防重放常用的 nonce 方案正交——nonce 管同一份签名在同一链上被执行几次，链数组语义管这份签名在哪些链上可以成立。对 NFT 用户，这类标准离日常最近的路径是跨链铸造与跨链领取：当你被要求签一份带多链字段的授权，先要求钱包或工具展示完整数组，拒绝签自己无法逐项复述的签名。按 ercs 仓库口径该提案为 Draft，属于规范草案而非部署事实。本文为机制说明，不构成任何投资建议。