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

核心提要：尽管消息签名不消耗Gas且不广播至链上，但其格式设计可能引发重放攻击。本文解析以太坊、比特币与卡尔达诺在签名机制上的差异，揭示看似安全的操作背后潜在的风险点。

数字签名中的隐性授权：为何签署消息并非无害

使用加密钱包签署一条消息，仅用于验证私钥持有权，并不会直接转移资产或提交交易。该操作不产生Gas费用，也不向区块链广播任何内容。然而，签名结果是否可被重复使用以触发特定行为，完全取决于所采用的签名格式及其语义定义。以太坊、比特币和卡尔达诺各自采用了不同的标准体系来规范此类签名。

以太坊：三类前缀结构决定签名用途边界

以太坊通过EIP-191定义了统一的消息签名框架，将数据组织为固定序列：以字节0x19开头，后接版本标识符，再附加版本相关字段，最终是待签名内容。选择0x19作为起始值，旨在确保生成的签名无法被误解析为有效的RLP编码交易——从而在结构层面区隔于真实交易。

EIP-191注册了三种版本码。版本0x00专用于嵌入预期验证合约地址的场景，典型应用如多签钱包中，通过组合前导字节、合约地址、金额、随机数及业务负载构建哈希，并调用ecrecover进行身份核验。此设计明确禁止跨钱包重用签名，实现目标绑定。

版本0x01对应于结构化类型数据的签名路径（即EIP-712），例如用户需对包含名称、版本号、链ID及验证合约等字段的域对象进行签名。而版本0x45则适用于personal_sign，其哈希前会添加特殊前缀“\x19Ethereum Signed Message:\n” + 消息长度，用以防范恶意dApp窃取形似交易的签名并加以复用。

值得注意的是，不同RPC实现间存在参数顺序差异：以Reown为例，personal_sign接收参数顺序为(message, account)，而eth_sign则相反，呈现(account, message)。这一细节仅来源于特定文档记录。

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

比特币的消息签名遵循BIP-137标准，长度为65字节，由1字节头部、32字节r值和32字节s值构成。头部字节兼具双重功能：低位比特表示恢复标识符，用于从签名中还原原始公钥；高位数值则指示签名来源的地址类型——根据规范，27-30代表未压缩的P2PKH，31-34为压缩的P2PKH，35-38对应P2SH封装的SegWit，39-42则指向原生bech32地址。

BIP-137明确指出，此类签名主要用于非交易性质的证明场景，如抵押担保、参与活动资格获取、空投申领或审计支持。它们本质是密钥控制权的静态证据，不具备自动执行能力，也不同于以太坊中可被合约调用的签名。

存在两项关键限制：首先，Taproot地址因采用Schnorr签名机制，无法从签名中恢复公钥，故不支持消息签名功能。其次，关于签名长度的分布特性——基于DER编码规则，约25%、50%和25%的概率分别导致71、72或73字节输出，这属于编码层面的统计现象，不影响签名的实际授权范围。

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

卡尔达诺的消息签名标准由开发者SebastienGllmt于2020年10月提出，旨在建立一套独立于交易签名的通用签名与验证机制。该规范即为CIP-8，其核心目标是为链上消息提供一致的表示方式。

实现CIP-30的钱包通过signData()接口暴露此功能，返回符合COSE_Sign1格式的结构体，并附带用于验证的COSE_Key。论坛示例表明，该流程依赖于底层的CIP-8标准。与比特币类似，卡尔达诺的消息签名仅用于证明密钥所有权，缺乏内置执行逻辑。目前尚无公开资料表明其存在类似以太坊预期验证者的动态执行模式。

常见误解：无成本即等于无风险

由于消息签名无需支付费用且永不进入区块浏览器，许多人误认为此类提示等同于普通登录操作，因而视为低风险。然而，规范本身并不支持这一泛化判断。EIP-191的版本0x00正是为了使签名能够被合约接收并转化为具体动作，如示例所示，签名可直接驱动后续逻辑执行。

同样地，EIP-712类型的签名与特定域和验证合约强绑定，虽尚未见生产环境实际用于资金转移的案例，但其架构已具备该可能性。相较之下，比特币与卡尔达诺的设计始终将签名定位为独立的归属证明，未预留执行入口。因此，判断某次签名的性质，应依据版本码与负载内容，而非是否收费。

本篇未覆盖的边界与局限

本文聚焦于以太坊、比特币与卡尔达诺三大生态的官方规范对消息签名格式的定义。它不涉及任何钱包客户端（如MetaMask）当前界面如何展示、警示或限制eth_sign、personal_sign或EIP-712请求，因缺乏统一的UI文档支持。同时，文中未引用现实世界中因签名重放导致资产损失的真实事件报告或审计记录，仅基于规范推演理论可行性。

此外，本文未涵盖Solana、Tron等其他链的消息签名约定，因其标准未形成广泛共识。关于Taproot不支持消息签名的说法，以及卡尔达诺CIP-8/CIP-30机制的具体实现，均仅依据单一来源（前者来自比特币维基，后者源自卡尔达诺论坛讨论）作出说明，不应被视为独立确认的事实。