跨链消息签名机制及其安全边界解析

通过加密钱包签署消息，本质上仅用于证明私钥控制权，不涉及资金转移或链上广播，无需支付Gas费。然而，该签名后续是否具备执行效力，完全取决于所采用的签名结构设计。以太坊、比特币与卡尔达诺分别定义了各具特色的格式体系，其安全性与用途存在显著差异。

以太坊：版本字节决定签名用途与可重放性

以太坊的ERC-191标准（由EIP-191发布）采用固定前缀结构：以0x19开头，紧随版本字节，再接版本特定数据，最后是待签名内容。选择0x19作为起始字节，旨在确保签名结果无法被误解析为有效的RLP编码交易，从而实现与真实交易在结构上的隔离。

该标准注册了三个版本字节。版本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)，这一细节仅来自该文档。

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

根据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编码特性，约25%、50%、25%的概率分别产生71、72或73字节的输出，但此与授权内容无关。

卡尔达诺：基于CIP-8与CIP-30的独立签名框架

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

论坛讨论明确指出，CIP-30依赖于CIP-8作为底层格式。与比特币类似，该机制本质为密钥控制权的独立证明，无内置执行路径。现有资料未记录卡尔达诺是否存在类似以太坊“预期验证者”的合约级调用模式。

对“无害签名”的普遍误解及其现实隐患

由于消息签名不消耗Gas且不会出现在区块浏览器中，常被误认为等同于登录操作，无实质风险。然而，规范本身并不支持这一泛化判断。EIP-191的版本0x00明确允许签名被提交至合约并触发执行，如其自身示例所示。EIP-712的类型化数据同样将签名绑定至特定域与验证合约，尽管尚未有公开案例证明其在生产环境中用于资金转移。

相较之下，比特币与卡尔达诺的消息签名格式被设计为纯粹的归属证明，不包含执行逻辑。一个签名提示属于何种类别，应依据版本字节与负载内容判断，而非是否产生费用。

本篇内容的局限性说明

本文仅基于已公开的规范文档，描述三链对消息签名格式的定义。未涵盖任何钱包界面（如MetaMask）当前如何呈现、警告或限制eth_sign、personal_sign或EIP-712请求，因缺乏官方UI文档支持。亦未引用现实中签名被重放至合约并完成资金转移的具体事件报告或审计分析，仅指出在理论上存在可能性。

内容范围限于以太坊、比特币与卡尔达诺，因其主要规范具有权威记录；未涉及Solana、Tron等生态的约定。关于Taproot不支持消息签名的说法，以及卡尔达诺CIP-8/CIP-30流程的机制，均基于单一来源（前者来自比特币维基，后者来自卡尔达诺论坛），在此标注，非独立事实确认。