币圈界报道：

通过签名证明私钥控制权的底层逻辑与链间差异

签署一条消息本身不会触发资金转移或上链操作，不产生Gas费用，也不广播任何交易数据。然而，该签名是否具备后续重放以授权特定行为的能力，完全取决于所采用的签名格式设计。以太坊、比特币及卡尔达诺各自定义了多套标准，其安全性与用途存在显著分野。

以太坊：三种版本字节对应不同信任模型

以太坊的 ERC-191 标准（由 EIP-191 提出）规定了统一的签名结构：以字节 0x19 开头，随后为版本标识符，再接版本专属数据，最后是待签名内容。选择 0x19 作为起始值具有明确目的——确保生成结果无法被误解析为有效的 RLP 编码交易，从而在结构层面区隔签名与真实交易。

该标准注册了三个版本。版本 0x00 专用于嵌入预期验证者地址的场景，即签名中直接包含一个目标合约地址。典型应用如多签钱包，通过组合 byte(0x19)、版本字节、合约地址、金额、随机数和负载数据，计算哈希并使用 ecrecover 验证签名者身份，进而执行相应动作。此设计旨在防止同一签名在不同钱包间被重复使用。

版本 0x01 对应 EIP-712 的结构化类型数据签名，例如用户需确认一个域对象（含 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 地址。该签名的设计初衷为惰性用途：用作抵押证明、信用评估依据、活动参与资格或审计支持，本质是密钥所有权的静态证明。

有两个关键限制：首先，Taproot 地址不支持消息签名，因 Schnorr 签名无法从中恢复公钥，导致无法与地址匹配。其次，关于签名长度的说明：由于 DER 编码特性，ECDSA 签名可能输出 71、72 或 73 字节，概率分别为 25%、50% 和 25%，但此差异不影响签名的有效性与授权范围。

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

卡尔达诺的消息签名标准 CIP-8 由开发者 SebastienGllmt 于 2020 年 10 月 5 日提出，旨在建立一套独立于交易签名的标准化消息签名机制。该文档强调其目标是为卡尔达诺生态提供统一的签名表示与验证方式。

支持 CIP-30 的钱包通过 signData() 方法对外暴露该功能。根据论坛示例，该方法返回 COSE_Sign1 结构体，并附带用于验证的 COSE_Key。社区讨论（包括用户 ATADA 于 2022 年 12 月 18 日的留言）表明，CIP-30 依赖于 CIP-8 作为底层格式基础。与比特币类似，卡尔达诺的消息签名仅为密钥控制权的证明，不内嵌执行路径，亦无类似以太坊“预期验证者”的自动调用机制。

常见误解：签名无害？并非绝对

尽管消息签名不收费且不上链，常被误认为等同于登录操作，因而无风险。但规范本身并不支持这种泛化判断。EIP-191 版本 0x00 明确允许将签名提交至合约并触发执行，如多签钱包示例所示。同样，EIP-712 类型化数据签名也绑定特定域与验证合约，虽尚未有公开案例显示其用于资金转移，但理论上已具备可行性。

相较之下，比特币与卡尔达诺的消息签名格式被设计为纯粹的归属证明，不具备内置执行逻辑。某次签名请求的性质，取决于版本字节与内容结构，而非是否支付费用。

本文未覆盖的边界与证据局限

本文仅聚焦于以太坊、比特币与卡尔达诺的官方规范对签名格式的定义，未涉及任何具体钱包界面（如 MetaMask）如何呈现或警告相关签名请求，因缺乏统一的 UI 文档支持。同时，文中未引用现实世界中签名被重放至合约造成损失的实际案例，仅基于规范推导理论可能性。

此外，本文未涵盖 Solana、Tron 等其他链的签名约定，因主要规范尚不完整或缺乏公开记录。关于 Taproot 不支持消息签名的说法，以及卡尔达诺 CIP-8/CIP-30 流程的运作机制，均仅依据单一来源（前者来自比特币维基，后者来自卡尔达诺论坛讨论）进行陈述，不代表经过多方验证的事实。