消息签名陷阱：看似无害实则可被重放攻击

核心提要：尽管消息签名不消耗Gas且不上链，但其格式设计可能引发重放攻击风险。本文解析以太坊、比特币与卡尔达诺在签名机制上的差异，揭示不同版本字节如何决定签名用途，澄清常见误解并指出规范层面的潜在漏洞。

通过签名验证密钥所有权：三类链的差异化实现

用户使用加密钱包签署消息，本质上是向外界证明自己掌握某私钥，这一过程不涉及资金转移，也不触碰区块链网络，无需支付交易费用或广播数据。然而，该签名后续是否可被重复使用以触发特定操作，完全取决于所采用的签名结构标准——以太坊、比特币和卡尔达诺各自发展出多套独立格式体系。

以太坊：三种签名版本对应三类安全边界

以太坊的 ERC-191 标准（由 EIP-191 定义）将签名内容组织为固定序列：以字节 0x19 开头，紧随其后的是版本标识符，再接版本特有数据，最后是待签名主体。选择 0x19 作为前导值具有明确目的——确保生成结果无法被误解析为有效的 RLP 编码交易，从而在结构上将签名消息与真实交易区分开来。

EIP-191 注册了三个版本号。版本 0x00 专用于携带“预期验证者”信息的场景，即在签名中嵌入一个特定合约地址。例如，多签钱包可通过组合 0x19、版本字节、合约自身地址、金额、随机数及负载内容，生成哈希后调用 ecrecover 验证签名者身份，进而执行相应操作。这种设计初衷正是为了防止同一签名被跨钱包复用。

版本 0x01 对应 EIP-712 的结构化类型数据签名，如 Reown 文档所示，用户需对包含 name、version、chainId 和验证合约等字段的域对象进行签名，而非原始文本。版本 0x45 则适用于 personal_sign 消息，其哈希前会添加前缀 "\x19Ethereum Signed Message:\n" + 长度。此前缀的存在旨在防范恶意 dApp 获取形似交易的数据签名，并将其用于冒充签名者。

值得注意的是，Reown 提供的 RPC 参考显示，personal_sign 的参数顺序为 (message, account)，而 eth_sign 为 (account, message)。该细节仅来源于 Reown 文档，未见于其他官方资料。

比特币：头部字节揭示地址类型与恢复能力

根据 BIP-137 与比特币维基，比特币消息签名长度固定为 65 字节：1 字节头部，后跟 ECDSA 签名中的 32 字节 r 值和 32 字节 s 值。头部字节兼具双重功能：低位比特表示“恢复标识符”，用于从签名中重建原始公钥；高位数值则指示该签名源自何种地址格式——27-30 对应未压缩的 P2PKH，31-34 为压缩版 P2PKH，35-38 表示 P2SH 封装的 SegWit，39-42 则指向原生 bech32 地址。

BIP-137 明确指出，此类签名的设计定位为“惰性用途”：主要用于证明密钥控制权，服务于抵押、信用评估、活动准入、空投资格或审计支持等非交易场景。与以太坊的合约驱动模式不同，这类签名不具备自动执行路径。

存在两项关键限制。比特币维基指出，Taproot 地址不支持消息签名，因 Schnorr 签名无法从中恢复公钥，故无法与特定地址匹配。此外，关于签名长度的附加说明：由于 DER 编码特性，ECDSA 签名实际长度可能为 71、72 或 73 字节，概率分别为 25%、50% 和 25%，但这不影响其授权效力。

卡尔达诺：基于 CIP-8 与 CIP-30 的标准化签名流程

卡尔达诺的消息签名标准 CIP-8 由开发者 SebastienGllmt 于 2020 年 10 月 5 日在官方论坛提出，目标是建立一套统一的签名表示与验证规范，区别于交易签名。支持 CIP-30 的钱包通过 signData() 方法提供该功能——2022 年 10 月发布的示例表明，该方法返回 COSE_Sign1 结构，并附带验证所需的 COSE_Key。

论坛讨论（包括用户 ATADA 于 2022 年 12 月 18 日的回复）确认，CIP-30 依赖于 CIP-8 作为底层格式基础。与比特币类似，卡尔达诺的消息签名仅用于密钥控制权证明，不包含执行逻辑。目前尚无记录表明其存在类似以太坊“预期验证者”的合约绑定机制。

警惕签名滥用：常见认知误区解析

由于消息签名不产生费用且不会出现在区块浏览器中，许多人误以为所有“签署此消息”的请求都无害，更接近登录行为而非金融操作。但规范本身并不支持这种泛化判断。EIP-191 版本 0x00 的设计正体现了签名可被合约消费的意图，如示例中通过哈希验证后直接执行负载。EIP-712 类型化签名同样绑定特定域与验证合约（如 Reown 所示），尽管尚未有公开案例证实其在生产环境中用于资金转移。

相较之下，比特币与卡尔达诺的消息签名被明确定义为独立的身份归属证明，不内建执行通道。一个签名的实际用途，取决于版本字节与载荷内容，而非是否支付费用。

本文未覆盖的关键事项说明

本文聚焦于三大主流链的签名格式规范定义，未涉及具体钱包界面（如 MetaMask）如何呈现、警告或限制 eth_sign、personal_sign 及 EIP-712 请求，因缺乏官方 UI 文档支持。同时，未引用任何现实世界中签名被重放至合约导致资金损失的案例，包括 EIP-712 “permit” 批准相关事件，仅基于规范推断其理论可行性。

本文仅涵盖以太坊、比特币与卡尔达诺，因其核心协议文档完备；未包含 Solana、Tron 等生态的签名约定。关于 Taproot 不支持消息签名的说法，以及卡尔达诺 CIP-8/CIP-30 流程机制，均依据单一来源（前者来自比特币维基，后者来自卡尔达诺论坛）提出，仅作事实标注，非独立验证结论。