钱包让你“签一笔交易”，签的其实不是一句人话，而是一串结构化的字节。在 Cosmos 生态里，这串字节该长什么样、怎么摆，先后被规定过三种答案：SIGN_MODE_LEGACY_AMINO_JSON、SIGN_MODE_DIRECT 和 SIGN_MODE_TEXTUAL。三者的接力关系，恰好是一部“怎么让用户在自己设备上看懂自己要签什么”的探索史，而最新的一章是退场：官方 ADR 明确记载，Textual 签名模式已在 Cosmos SDK v0.55 中被移除，协议里的枚举值保留为 reserved，这份 ADR 改为仅作历史参考。
Direct 是什么，为什么设备读不懂
现行主流是 SIGN_MODE_DIRECT。按官方文档的交易结构示例，一笔交易序列化成 Protobuf 字节后分三块：交易本体（消息列表）、auth_info（签名人公钥、序列号、费用，其中 mode_info 里写明 SIGN_MODE_DIRECT）和签名数组。序列化成统一字节格式的意义，官方说得很直白：确保每个验证者对同一笔交易作完全相同的解释；一笔交易里的多条消息按出现的顺序依次执行。ADR 050 回顾历史时写道：Direct 由 ADR 020 引入，意图在绝大多数场合（移动钱包、命令行密钥环）取代 Amino JSON；问题在于 Direct 的签名字节是二进制的，不适合直接给人看。硬件钱包原则上可以把原始字节滚给你，但那等于逼用户盲签；而要把字节还原成字段名，设备得内置整套 Protobuf 类型定义，Ledger 这类设备的内存装不下。于是同一份 ADR 记录了一个尴尬的中间态：Ledger 硬件钱包当时仍靠 Amino JSON 才能把签名内容渲染成可读文本。
Textual 的解法：先渲染，再签名
SIGN_MODE_TEXTUAL（ADR 050）的思路是倒转顺序：不是“先拿字节再想办法显示”，而是先把交易渲染成一串称为“屏”（screen）的结构化文本，人确认后，签名对象就是这串屏经 CBOR 编码的字节。渲染不是本地字典翻译，而是链上状态参与的重排：显示代币要读链上的面额元数据，地址可以显示成账户主人登记的别名，语言偏好也来自链上状态。官方为此设定了严格的验证规则：这笔签名基于哪一时刻的链上状态渲染，验证时就还是那一套；如果从签名到交易进块之间状态变了，重新渲染的结果对不上，签名无效，整笔交易被拒收。ADR 还把“用户应当能在一台显示能力有限的简单安全设备上对所签内容作出知情同意”列为签名应当满足的三条安全性质之一。示例屏的字段骨架包括链标识、账户编号、序列号、地址、消息条数与逐条消息、备注、费用、手续费代缴人与补贴方、小费、Gas 上限、超时高度，以及其他签名人的签名信息。
为什么最后又被移除
时间线上，这份 ADR 起草于 2021 年 12 月，2022 年 2 月获 Ledger 团队概念确认，同年 5 月转为 Accepted，8 月修订为要求对交易原始字节签名，11 月定型 CBOR 编码，2023 年 3 月引入规范版本号（初始为 0）。而现在的状态栏写着 Archived：v0.55 移除、枚举值 reserved、文档留作历史。ADR 正文没有给出一段正式的“移除理由”，但它在写就当天就自陈过局限：公钥等字段仍以十六进制呈现，并非人可读；交易复杂时屏可以无限长，用户可能跳着屏继续盲签；硬件端还需要专门发布新应用来支持。约束条件（生态未迁移、多客户端实现成本）与这些已知短板之间的取舍，官方文档没有展开，这里不作猜测。对你实际的影响很朴素：今天对接 Cosmos 系链的硬件签名路径，仍是“设备能解析消息类型的可读签名”加“解析不了就回到四查纪律”，而不是 Textual。
用户该记住的三条
第一，别把“弹出 JSON”和“弹出字节”当成安全与否的分界，关键看设备能不能独立还原出收款地址、金额与单位、链标识这几个字段；第二，Ledger 显示的是 JSON 时，那是 Legacy Amino JSON 通道在工作，字段名、面额单位和目标地址仍要逐项核对，这类核对的完整清单在 盲签风险是什么？签名前四查 讲过；第三，签名模式是协议层概念，钱包与交易所支持哪几种、界面怎么呈现，以各自现文为准——本文机制以 Cosmos SDK 官方文档与 ADR 在 2026-10 抓取版本为准。涉及资产的签名决定都不构成投资建议，机制解读也不替你核对具体金额。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。