按链和版本字节，消息签名实际授权了什么

免责声明：内容不构成买卖依据，投资有风险，入市需谨慎！

用加密钱包签署消息证明你控制着一个私钥

这一行为本身并不转移资金，也不会触及区块链——无需支付 Gas，也不会广播任何内容。然而，该签名日后能否被重放以授权某项操作，完全取决于所使用的签名格式；以太坊、比特币和卡尔达诺各自定义了多种格式。

以太坊：三种版本字节，三种不同保证

以太坊的 ERC-191 标准（以 EIP-191 发布）将签名数据定义为固定结构：字节 0x19，后跟版本字节，再后跟版本特定数据，最后是被签名的数据。EIP-191 指出，选择前导字节 0x19 是有意为之，目的是使结果永远无法被解析为有效的 RLP 编码以太坊交易——签名消息与签名交易在结构上被区分开来。

在该结构中，EIP-191 注册了三个版本字节。版本 0x00 用于带有“预期验证者”的数据——即一个被嵌入签名内容的特定合约地址。EIP-191 给出了一个 Solidity 示例：多签钱包函数通过组合 byte(0x19)、版本字节、address(this)、交易金额、随机数和负载来重构哈希，然后在该哈希上调用 ecrecover 以验证签名者身份，随后执行负载。这种签名从一开始就设计为交给合约并转化为操作——根据 EIP-191，预期验证者字段的全部意义就在于防止为一个钱包创建的签名被重放用于另一个钱包。

版本 0x01 对应于 EIP-712 结构化、类型化数据——Reown 文档中展示的格式示例：用户签名一个域作用域对象（包含 name、version、chainId 和验证合约等字段），而非原始字符串。版本 0x45 涵盖 personal_sign 消息，其哈希前会添加前缀 "\x19Ethereum Signed Message:\n" + 长度。Reown 文档和 EIP-191 均指出，该前缀的存在是为了防止恶意 dApp 获取实际上形如交易数据的签名，并重用它来冒充签名者。

一个值得注意的集成细节：Reown 自身的 RPC 参考显示 personal_sign 的参数顺序为 (message, account)，而 eth_sign 的参数顺序相反 (account, message)。此细节仅来自 Reown 文档。

比特币：头部字节告诉你哪个地址类型进行了签名

根据 BIP-137 和比特币维基，比特币消息签名为 65 字节：1 字节头部，后跟来自底层 ECDSA 签名的 32 字节 r 值和 32 字节 s 值。头部字节同时承担两项功能。其低位比特编码了“恢复标识符”，用于从签名中重建正确的公钥。其余字节的数值则告诉验证者该签名由哪种地址格式生成：根据 BIP-137，27-30 对应未压缩的 P2PKH 地址，31-34 对应压缩的 P2PKH，35-38 对应 P2SH 封装的 SegWit，39-42 对应原生 bech32 地址。

BIP-137 将此类签名的实际用途定义为设计上的惰性：证明资金用于抵押或信用评估、进入活动资格、获得空投资格或支持审计。在每种情况下，签名都是某个时间点上密钥控制权的证明——它不像以太坊的预期验证者签名那样会被合约消耗。

有两个值得注意的限制。根据比特币维基，Taproot 地址不支持消息签名，因为 Schnorr 签名（与 ECDSA 不同）无法从签名中恢复公钥，因此 Taproot 签名无法与地址匹配。另外，作为签名构造方面的旁注（而非安全性），BIP-137 指出 ECDSA 签名大约有 25%、50% 和 25% 的概率分别产生 71、72 或 73 字节——这是关于 DER 编码的细节，与签名授权的内容无关。

卡尔达诺：CIP-8 与 CIP-30 的 signData() 调用

卡尔达诺的消息签名标准 CIP-8 由开发者 SebastienGllmt 于 2020 年 10 月 5 日在卡尔达诺论坛上提出。正如论坛帖子所述，该文档“试图为卡尔达诺设置一个表示和验证签名消息的标准”，与交易签名相区分。实现 CIP-30 的钱包通过 signData() 方法暴露此功能——正如 2022 年 10 月 24 日发布的论坛示例所示，该方法返回一个 COSE_Sign1 结构，并附带一个验证所需的 COSE_Key。论坛贡献者（包括用户 ATADA 于 2022 年 12 月 18 日发布的消息）指出，CIP-30 依赖 CIP-8 作为其底层签名和密钥格式。与比特币的方案类似，CIP-8 消息签名是一种密钥控制证明机制，与交易不同；该论坛讨论并未记录卡尔达诺中与以太坊预期验证者执行模式相对应的功能。

常见的误解

由于消息签名无需 Gas 且永远不会出现在区块浏览器上，人们很容易将每个“签署此消息”的提示视为无害——更接近登录而非交易。但相关规范并不支持将其作为一概而论的规则。EIP-191 的版本 0x00 正是为了让签名消息可以交给合约并据此执行（根据 EIP-191 自身的示例）。EIP-712 类型化数据（版本 0x01）同样将签名绑定到特定域和验证合约（如 Reown 示例所示），尽管现有证据并未扩展到记录 EIP-712 签名如何在生产环境中用于转移资金。相比之下，比特币和卡尔达诺的消息签名格式被设计为独立的归属证明，没有内置的执行路径。某个签名提示属于哪一类，取决于版本字节和负载内容，而非是否收取了费用。

本页未说明的内容

本页描述了规范对签名格式的定义。它并未描述任何特定钱包界面（包括 MetaMask 或其他）当前如何标记、警告或限制 eth_sign、personal_sign 或 EIP-712 签名请求，因为没有可用的钱包 UI 文档作为证据。它无法引用现实世界中签名消息被重放到合约以转移资金的案例（包括涉及 EIP-712 “permit” 批准的案例），因为这里没有提供任何事件报告或审计——只有规范本身，使得这种重放在理论上成为可能。它仅涵盖以太坊、比特币和卡尔达诺，因为这三个链的主要规范有据可查；它未提及 Solana、Tron 或其他生态系统的消息签名约定。最后，Taproot 地址不支持消息签名的说法，以及卡尔达诺 CIP-8/CIP-30 流程的机制，各自仅基于本证据集中的单一来源（前者来自比特币维基，后者来自卡尔达诺论坛讨论），在此标注，而非作为独立确认的事实。