为什么有些区块链能显示你签名的内容，而有些却做不到？

第一层：架构透明——交易意图天生可读

有四个生态因协议设计本身就支持明文签名而脱颖而出，无需依赖外部工具。

XRP Ledger

XRP Ledger 在主流区块链中明文签名能力最强。其架构采用约 50+ 种枚举交易类型（如 Payment、OfferCreate、TrustSet、EscrowCreate、NFTokenMint 等），每种类型都有完整定义的字段和类型。

其二进制格式自描述——TransactionType 字段让解析完全确定，所有字段结构在 rippled 源码定义文件中维护。

硬件钱包可以显示每种已知交易类型的所有字段：收款人、金额（含代币的币种与发行方）、手续费、备注及特定参数。账户模型让金额明确，无 UTXO 复杂性，手续费为单独字段而非隐式计算。

当前主网交易几乎 100% 可明文签名。唯一风险是协议新增交易类型（如近期 Vault、Loan 操作）时需钱包应用更新；未知类型则回退为盲签。

Polkadot / Substrate

Polkadot 拥有业内最复杂的明文签名方案。其运行时元数据系统（MetadataV14/V15）为每个 pallet（模块）、调用和数据类型提供完整自描述的类型注册表。

每笔交易（extrinsic）结构为 pallet_index || call_index || encoded_arguments，元数据精确告知各索引含义及参数解码方式。

最大挑战是完整元数据超 200KB，远超硬件钱包约 64KB 内存。RFC-0078（Merkleized Metadata）通过 Merkle 树仅传输相关子集（交易所需类型）及加密证明。

元数据哈希通过 CheckMetadataHash 签名扩展在链上校验，实现信任最小化。这样，一个通用 Ledger 应用即可支持所有 Polkadot 平行链和中继链，无需单独适配。

该方案还能优雅应对运行时升级，即使索引变更，只需新元数据和证明即可确保签名准确。

Cosmos / Tendermint

Cosmos/Tendermint 采用类型化消息架构，每笔交易包含一个或多个 sdk.Msg 对象，封装于 Protobuf 的 google.protobuf.Any，并通过 type_url 字段标识消息类型。
标准消息如 MsgSend、MsgDelegate、MsgVote 等有明确结构。

生态专用明文签名方案为 SIGN_MODE_TEXTUAL（ADR-050），自 Cosmos SDK v0.50 起引入。它将交易渲染为适合小屏幕的多页（约 40 字符），通过 value renderers 将原始数据转为可读格式：如“2 ATOM”而非“2000000uatom”，地址用 bech32，时间戳用 RFC3339。

开发者可为自定义消息类型提供渲染器（要求格式化与解析函数可逆）。签名载荷包含文本和原始字节哈希，保障安全性。

NEAR Protocol

NEAR Protocol 通过多项架构设计优先保证可读性。账户标识为“alice.near”这类人类可读名，而非十六进制地址。

交易包含类型化 Action 枚举（Transfer、Stake、FunctionCall、AddKey 等），始终可识别。尤其 FunctionCall 动作包含明文方法名（如“transfer”、“set_greeting”）及默认 JSON 序列化参数。

硬件钱包可显示：“在 app.defi.near 调用方法 'swap'，参数：{amount: 1000, token: 'usdc.near'}。”比任何基于选择器的系统都直观。主要限制在于部分合约为节省 Gas 采用 Borsh 序列化参数，若无结构定义则难以解析。

第二层：有条件透明——基础操作可明文，智能合约引入不透明

基础层操作明文签名体验良好，但一旦引入通用可编程性，透明度大幅下降。

Bitcoin

Bitcoin 的交易模型即使无智能合约，也存在明文签名难题。UTXO 模型导致原始交易不含输入金额——输入仅引用前置输出的哈希和索引，但不包含金额。

因此，硬件钱包无法计算手续费（等于输入总额减输出总额），也无法确认是否被诱导多付。PSBT（BIP 174） 通过为未签名交易附加 UTXO 元数据及 BIP32 派生路径，解决找零地址识别问题。

有了 PSBT，硬件钱包可清晰显示收款地址、金额和手续费，覆盖约 90% 常规交易。多签、锁定脚本、Taproot 等复杂场景则增加难度——P2SH、P2WSH 用哈希隐藏任意脚本，Taproot 的 MAST 结构让备用花费条件在未使用前不可见。

Aptos

Aptos 受益于 Move 强类型系统和链上 ABI。交易载荷包含完整函数标识（如 0x1::aptos_account::transfer），模块地址、名称、函数名均可见。

SDK 可查询链上 ABI 以反序列化 BCS 参数。即有 ABI 的硬件钱包可显示：“调用 0x1::aptos_account::transfer（recipient: 0xABC..., amount: 1000）”。

但 BCS（Binary Canonical Serialization）本身不自描述，若无 ABI 结构，原始 BCS 字节无法解析。脚本型载荷（任意 Move 字节码）完全绕过结构化入口函数。Ledger Aptos 应用专设“启用盲签”选项，体现简单与复杂操作间的鸿沟。

Stellar

第二层最典型代表。其 26 种经典操作（Payment、ChangeTrust、ManageSellOffer 等）结构固定，完全可解析——Ledger 应用可分步显示操作类型、金额、目标、资产、备注和手续费，经典操作覆盖率约 95%。

• Soroban 智能合约（2024 年上线）重新引入 Ethereum 式不透明问题。调用以 InvokeHostFunction 操作到达，合约地址为不透明格式，参数为需合约特定知识解码的 ScVal 类型。无外部元数据，Soroban 原始交互几乎无法明文签名。

Algorand

七种类型化交易（Payment、Asset Transfer、Asset Configuration、Key Registration、Application Call、Asset Freeze、State Proof）均可通过 MessagePack 完全解析。ARC-4 ABI 标准为合规智能合约提供方法签名、参数名及描述。

• 非 ARC-4 合约参数不透明。
• 所有智能合约最多可生成 256 个内部交易——可嵌套 8 层，签名时完全不可见。

Cardano & Tezos

Cardano 的 eUTXO 模型可清晰显示简单交易的输入、输出、手续费和多资产数值。但 Plutus 脚本涉及的 datums 和 redeemers 是任意 CBOR 结构，无标准解析格式。CIP-21 明确指出 Plutus 模式“为极致灵活性而牺牲用户可读性”。

Tezos 结构上有优势——合约参数类型链上存储，入口点用字符串名而非哈希选择器，避免冲突。但 Micheline 二进制编码仍需合约类型结构才能完全解析，Ledger Tezos 应用也承认复杂参数显示有限。

❌ 架构本身不透明——明文签名几乎无解

这里的难题源于协议设计本身，而非工具缺陷。外部元数据虽可一定程度补救，但无法根本改变架构。

Ethereum / EVM Chains

最典型、研究最深入的案例。用户与智能合约交互时，交易 data 字段包含 4 字节函数选择器（keccak256 签名前 4 字节），后接 32 字节 ABI 编码参数。若无合约 ABI JSON（链上未存储），这些内容仅为十六进制乱码。硬件钱包看到 0xa9059cbb000...03e8，无法知晓其含义（如“转账 1000 代币至 0xABC...”），除非有外部元数据。

EVM 生态还存在多重复杂性：

• 函数选择器冲突：4byte.directory 数据库已收录近百万签名，32 位空间早已过“生日悖论”阈值，不同函数可生成相同选择器。
• 代理合约：通过 delegatecall 路由执行，底层实现合约地址可随时变更。Bybit 盗窃案正是利用了此漏洞。
• 多重调用（Multicall）：将 ABI 编码的 calldata 嵌入参数，需递归解码。
• EIP-712：提升链下消息（如授权、订单）可读性，但不解决链上交易不透明。

Solana

明文签名难度最高的架构之一。交易指令包含 program_id、账户列表和不透明字节数组，无统一 ABI——每个程序自定义序列化格式。Anchor 框架采用 8 字节 discriminators（SHA-256 指令名），但仅为框架约定，非协议要求。许多程序未用 Anchor，也未公开 IDL。

• 版本化交易中的地址查找表将 32 字节地址压缩为 1 字节索引——硬件钱包无法校验查找表内容，因为无法访问链上数据。Solana 官方文档已明确承认此问题。
• 跨程序调用（CPI）链在签名时完全不可见。
• 简单 SOL 转账和 SPL 代币操作——Ledger 可解析。但 DeFi 交互（占 Solana 交易量绝大多数）几乎只能盲签。

TON

多项架构特性叠加，单独就已难以明文签名，何况组合出现：

• 基于 Cell 的数据结构：所有数据以 Cell 树表示（每 Cell 最多 1023 位及 4 个引用），解析超单 Cell 消息需递归遍历。
• TL-B 编码：位级操作，构造器和递归引用极其复杂，远比字节对齐格式难以在硬件上解析。
• 无统一 ABI：32 位操作码仅为惯例，非协议强制。
• 异步执行：单次用户操作可在后续区块内跨多个合约和分片级联触发内部消息。用户仅签首个外部消息，下游过程签名时完全不可见且难以预测。

Sui（特别提及）

与 Aptos 一样采用 Move 强类型系统，有助于指令级解析。但 Sui 的可编程交易块（PTB）可包含多达 1,024 条命令，操作间结果可链式传递——如拆分代币、存入 DeFi、抵押借款、转账，一次原子完成。尽管单条命令类型明晰，但要在硬件钱包屏幕上直观展示多步 PTB，极具 UX 挑战。理解完整交易需分析所有命令及其数据依赖。