为什么有些区块链隐藏了你签名的内容

当你在硬件钱包上批准一笔加密交易时，通常有两种情况：要么你能在屏幕上看到清晰明了的交易摘要，知道即将发生什么；要么只能看到一堆十六进制代码，盲目签名，靠运气。盲签（blind signing）就是在无法以人类可读方式核查全部细节的情况下批准数字交易。
 

2025年2月，盲签成为 $15亿 Bybit 黑客事件的关键推手，这是加密史上最大的一次盗窃案。攻击者并未攻破任何密码学算法，而是利用了用户无法分辨常规转账和恶意合约升级的事实。
 

你的钱包能否在签名前显示清晰、可读的摘要，并不是软件好坏的问题，而取决于每条区块链协议层的设计。有些链天生支持交易自描述，信息一目了然；有些则将关键信息隐藏在二进制数据中，必须借助外部资料才能解读。本文将解析这些设计差异在主流区块链上的体现，以及对你资产安全的影响。

三层分级框架

明文签名是一种安全流程，让你能在安全屏幕上，以人类可读的方式核查数字交易的全部细节后再决定是否批准。 

在13个主流区块链生态中，明文签名的支持程度根据协议架构分为三大层级。这不是评判哪条链好坏，而是多年前协议设计时的权衡，很多安全隐患当时并未被充分认识。

第1层级：为透明而生

这些区块链的设计天生支持明文签名。核心原因在于它们采用了有限类型的结构化交易，每个字段都有名称、类型和明确定义的模式。硬件钱包无需外部信息即可解析，交易本身就说明了用途。

The XRP Ledger 或许是所有主流链中明文签名体验最完善的。其二进制交易格式包含 TransactionType 字段，支持50多种交易类型（如 Payment、OfferCreate、TrustSet、EscrowCreate 等）的确定性解析。每个字段都有明确定义，硬件钱包可直接显示收款人、金额、手续费、备注及所有特定参数，无需查阅外部资料。几乎100%的主网交易都可实现完全明文签名。

Polkadot 通过 运行时元数据系统（MetadataV14/V15）实现了业内技术最先进的明文签名方案。每笔交易都引用 pallet 和 call 索引，元数据能精确说明索引含义及参数解码方式。难点在于完整元数据超过200KB，超出大多数硬件钱包的内存限制。 

解决方案是 RFC-0078（Merkleized Metadata），通过加密树结构仅传输相关子集，并在链上验证包含性证明。这样，Ledger等厂商只需一个应用即可支持所有 Polkadot 平行链，无需单独适配。
 

Cosmos 采用类型化消息架构，并通过 SIGN_MODE_TEXTUAL 标准（ADR-050）（Cosmos SDK v0.50 引入），将交易渲染为适合小屏幕的人类可读界面。币种金额会显示为 “2 ATOM” 而不是 “2000000uatom”。NEAR Protocol 更进一步，支持 人类可读账户名（如 “alice.near”）及 JSON 序列化的函数参数，钱包可直接明文显示。
 

第2层级：基础操作明文，复杂合约变“黑盒”

六大生态在原生操作上支持明文签名，但一旦涉及智能合约，透明度就大幅下降。比特币就是典型例子。UTXO 模型下，原始交易不包含输入金额，硬件钱包无法仅凭交易本身计算手续费，必须查前序输出。 PSBT（BIP 174）解决了大约90%常规支付场景，但 Taproot 脚本路径和复杂多签仍然存在信息不透明。
 

Stellar 的分层最为明显。其26种经典操作（如 Payment、ManageSellOffer、ChangeTrust）有固定结构，硬件钱包显示友好。但 2024 年上线的 Soroban 智能合约，重新引入了 EVM 风格的不透明：参数以编码二进制形式传递，需合约特定知识才能解读，经典操作的明文覆盖率从约95%骤降至 Soroban 场景几乎为零。Algorand、Cardano、Aptos、Tezos 也有类似模式：原生操作明文，复杂合约交互则存在巨大信息盲区。
 

第3层级：架构自带“黑盒”

三大生态的架构设计让明文签名几乎无解，无论钱包软件多优秀都难以突破。这也是为什么主流 DeFi 界面几乎都要弹出盲签风险提示。
 

Ethereum 及所有 EVM 兼容链的核心问题是：ABI 编码本身不自描述。调用智能合约时，交易数据字段只包含4字节函数选择器（函数名哈希前四字节）和32字节参数，没有合约 ABI 的 JSON 文件，看到的就是一串十六进制乱码。ABI 不会上链，硬件钱包无法得知 0xa9059cbb... 代表“转账1000 USDC 到 0xABC...”，除非有外部元数据。
代理合约（Proxy contracts）更复杂，执行入口地址可变，也是 Bybit 黑客事件的攻击手法。
 

行业的应对是 ERC-7730，这是2024年提出的元数据标准，提供 JSON 文件描述如何解码和展示特定合约交互。它确实有效，但前提是有人为每个合约都编写并维护元数据文件。从本质上说，这只是给架构本身不透明的问题打了个补丁。
 

Solana 难度更高。交易指令只包含程序ID和一段无标准 ABI 的字节数组，每个程序自定义序列化格式。Anchor 框架用8字节 discriminator 提供了半标准方案，但许多项目既不用 Anchor，也不公开接口定义。DeFi 场景下，Solana 绝大多数交易都只能盲签。

TON 则因异步执行更复杂：你签的只是初始消息，后续区块的所有动作在签名时都是不可见的。

 实用总结

最实用的建议：在用硬件钱包参与 DeFi 之前，先搞清楚你的链属于哪一层。第1层链，明文签名体验理想；第2层链，普通转账可以放心签，复杂合约交互要多查资料；第3层链，DeFi 交易必须格外警惕，务必确认 dApp 和钱包是否支持 ERC-7730 元数据，否则任何重要操作都要慎重。
 

硬件钱包厂商正在积极改进。例如 Ledger 的 Generic Parser 能读取 ERC-7730 元数据，并在安全屏幕上展示明文详情。

Polkadot 的 Merkleized Metadata 方案被认为是业内最优雅的解决思路：无需信任、加密验证、协议原生。行业正向更好的标准迈进，但第3层链的底层协议限制短期内难以消除。
 

最简单的判断规则：如果你的钱包只显示一串哈希或十六进制流，让你直接签名，请务必提高警惕。

参考资料与延伸阅读

以下资源可深入了解本文涉及的协议与标准：