以太坊上最常见的签名串是 130 个十六进制字符，对应 65 字节：32 字节 r、32 字节 s、再加 1 字节 v。ERC-2098 提出了一个 Final 状态的紧凑表示：把第三段折进 s 的最高位，只留 r 与 yParityAndS 两个 32 字节段，共 64 字节。少一个字节看似寒酸，它为什么值得单独立一个标准、又在哪些地方真的出现了，本文按规范文本讲清楚。
一个字节里装的是什么
ECDSA 签名验证时，除了 r、s 还需要一个恢复标识（recovery id，或叫奇偶位 yParity），用来从签名本身反推出公钥。它的全部信息量只有 0 或 1 级别的区分，却常年独占一整字节。ERC-2098 的做法简单直接：把这一位塞进 s 的最高比特位，其余 255 位仍装原来的 s。规范同时给了两条转换规则：标准 65 字节签名去掉了冗余可以转成紧凑形式；紧凑形式拿回最高位也能还原成 65 字节，两边是无损的双向换算。需要 ecrecover 这类只认经典入参的合约做链上验证时，把紧凑签名展开即可，验出来的结果是同一件事。
省一个字节，为什么值得立项
收益分三处。传输与存储上，凡是大量签名要随交易或日志搬运的场景，每枚省一个字节——EIP-1559 的交易回执里，日志字段记录授权信息时采用的正是这种 64 字节紧凑格式，这是它最具体的落地。费用上，链上每写一个字节都要付 gas，签名批量验证的协议会算这笔账。工程上，64 字节正好等于哈希长度，工具链按定长数组处理更顺手。规范也坦承局限：64 字节方案在个别场景（比如某些哈希进 Merkle 树的用法）不如 65 字节省事，所以它定位是”可用可选的表示层标准”，不是取代经典格式。
用户在哪里会真正遇到它
签名弹窗本身不露长度：你在钱包里确认一笔链下签名（作用区别见 签名不花 Gas，但不等于免费：链下签名与链上交易的安全边界），看不到 64 还是 65 字节。真正遇到它的时刻有三类。第一类是 gasless 与中继类流程：协议把签名塞进 calldata 交给执行方代付，文档里出现 yParityAndS、compactSignature 字样的就是这套表示。第二类是开发调试：跨库对接时”签名长度不匹配”的报错，十有八九是两种表示之间忘了换算——规范给了对照表，先核对字段名再怀疑签名本身坏了。第三类是读回执：直接解析类型 2 交易的原始回执时，日志里的授权签名就是 64 字节形态，按 65 字节硬解会把尾部错位。对只通过钱包和区块浏览器使用资产的用户，这份标准属于背景知识，不需要也不应该为它做任何额外操作。
边界与澄清
三点值得点名。其一，压缩的是表示不是安全参数：r、s 的长度没动，折叠的那一位本来就不承载强度，签名抗伪造能力与经典写法完全一致。其二，它不是新签名算法：底层仍是 secp256k1 上的 ECDSA，只是写下来的形状变了，别把它与”更安全的签名”这类宣传词挂钩。其三，链上验签消息格式的家族谱系（如消息前缀、结构化签名）决定的是”签的是什么”，ERC-2098 只回答”签名怎么编码”，两层互不混用，把证明地址归属的消息签名与这笔交易签名弄混也是常见误区，可对照 怎么证明地址是你的？消息签名验证工具的使用与边界。
一分钟自检
如果你在集成中拿到一串签名字段：130 个十六进制字符、末尾两位在 00 到 1f 一带波动——经典 65 字节；128 个字符且首段 64 字符干净——紧凑格式，按最高位展开再验。两条路殊途同归，识别错了只会浪费排查时间，不会造成资产后果；反过来，任何声称”必须用紧凑格式才安全”的说法，都不符合规范原文。
本文为格式类机制科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。