交易到底在对什么求签:EIP-6493 的 SSZ 签名方案与域分离防混淆 图 1
交易到底在对什么求签:EIP-6493 的 SSZ 签名方案与域分离防混淆 · 图 1

钱包签名时你看到的是一串确认按钮,密码学层面发生的却是“对某个 32 字节哈希求签”。这个哈希怎么算出来,直接决定了攻击者有没有机会“张冠李戴”——拿你为 A 场景签的签名去冒充 B 场景。EIP-6493 就是围绕这个问题写给未来交易编码的一份签名方案,状态为 Draft,即草案,尚未定稿也未进入主网。它依赖 EIP-6404 定义的 SSZ 交易结构,今天不会改变你手头任何一笔交易,但设计思路对理解签名安全非常值得读。

为什么签名哈希要做域分离

数字签名只对哈希负责,不关心哈希背后是什么。如果两种不同用途的签名对象碰巧算出同一个哈希(哈希碰撞),一个签名就能在两个场景里同时成立。防御手段叫域分离:在哈希输入里掺进一个标明“我是哪类东西”的常量前缀或后缀,让不同类别的签名对象无论内容如何都不会撞上。你已经在现有机制里见过这个思想:钱包弹出的结构化签名窗口:域名信息四行到底在防什么 讲过的 EIP-712 结构化签名,其最终摘要以固定字节序列开头并嵌入域分隔符,本质上就是域分离。EIP-6493 做的事完全同构,只是对象换成了“原生 SSZ 编码的交易”和“SSZ 授权”。

交易到底在对什么求签:EIP-6493 的 SSZ 签名方案与域分离防混淆 图 2
交易到底在对什么求签:EIP-6493 的 SSZ 签名方案与域分离防混淆 · 图 2

两个域类型分别管什么

按提案规格,原生 SSZ 交易的签名哈希由一个名为 ExecutionSigningData 的容器算出,字段只有两个:被签对象自身的 hash_tree_root,和一个 DomainType 域类型值。提案分配了两个值:签交易用 DOMAIN_TX_SSZ,即 0x01000008;签授权用 DOMAIN_AUTH_SSZ,即 0x02000008。也就是说,同一份字节内容,放进“交易”域和放进“授权”域会得到两个必然不同的签名哈希,任何一方都不能冒充另一方。提案还规定:厂商自定义网络必须为自家的自定义交易或授权类型使用不同的域类型值——这条规定针对的正是“测试网和主网共用一套常量导致签名可跨网重放”这类历史教训的变体。另外一个细节是,原生 SSZ 交易的载荷里不再带 RLP 时代 EIP-2718 的类型字节,类型的区分职责被域类型和容器结构本身接管;想了解旧信封里类型字节的位置,可以对照 一串交易十六进制怎么读:类型字节、字段顺序与签名尾巴的位置

与 EIP-712 的分工

两者很容易被混为一谈,实际管的是两条不相交的流水线。EIP-712 服务链下签名:登录验证、许可式授权、/off-chain 投票等,签出的东西通常不上链、不消耗 Gas,由合约或服务器事后验证。EIP-6493 服务链上交易本身:它规定的哈希就是 secp256k1 求签的输入,决定的是“这笔交易能否被网络接受”。一个帮助你判断按钮含义的直觉:如果钱包弹窗里出现逐字段的可读结构、域名和版本号,多半走 712 流水线;如果是花费、转账、改变状态并显示 Gas 费,那求签的是交易哈希。草案里的域常量做法若落地,会进一步压缩“同一把钥匙在不同编码体系里被滥用”的空间。

钱包用户现在该做什么

诚实地说:目前什么都不用改。EIP-6493 依赖的 SSZ 交易本身也还在草案阶段,主网交易仍是 RLP 编码。它对你的现实意义有两层。第一层是理解:为什么负责任的钱包在不同场景从不复用同一签名接口——签名对象的种类边界,正是靠这类域分离机制在协议层守住。第二层是识别风险话术:如果有人宣称“升级后的新编码天然更安全所以请安装某工具”,这是把草案状态偷换成既成事实的营销话术;编码演进即使发生,也一定经过 EIP 流程定稿、客户端实现和升级公告,而不是某个下载链接。

自查顺序与常见误判

看签名请求时按三步走:先分类型——这是链上交易还是链下签名;再看域信息——712 类签名核对域名、版本与校验合约地址,交易类核对链号与接收合约;最后看范围——授权的额度、期限和可撤销性。常见误判有两类:一是把“哈希算法安全”误解为“签名用途安全”,哈希不碰撞不代表你不该在不同用途间复用同一把私钥;二是把不同提案的域常量记串,交易域、授权域、应用域的常量各属各的规范,检索时以规范原文表格为准,不要靠记忆拼十六进制。

小结

EIP-6493 用一个小容器和两个域常量回答了签名安全里一个朴素问题:让每类签名对象天生带有身份标签。草案就是草案,但它示范的域分离纪律,早已在 712 和现网交易里保护着每一次点击。本文内容为机制科普,不构成任何投资建议;涉及私钥与签名操作时请以钱包官方文档为准。