备份可以放云端：BIP-138 给钱包描述符做的紧凑加密

自托管者常见的备份两难：描述符文件明文放家里，搬家丢、火灾丢；扔进网盘，等于向云服务商公开“我用几把什么钥匙、几个人共管、管哪些地址”——这些元数据不是私钥，却是拼图里相当靠外的几块。BIP-138 想给这层非私钥数据一个体面的出路：一套紧凑加密格式，把描述符、钱包策略与标签备份原样加密成一小段密文，密钥直接由描述符里的公钥按固定规则推导，任何持有一把合法公钥的人无需额外秘密就能解密。提案编号 138，标题“Compact Encryption Scheme for Non-seed Wallet Data”，Draft，版本号 0.1.3，依赖列着 32、340、380、388、389、390 一串编号，讨论链接指向 2026 年的社区线程。

先划清它管什么：明文只许装输出描述符、钱包策略和同类元数据，明文含私钥就违背设计前提——提案把这句写成硬约束。它管不了的也说在前面：加密不改变公钥可被重算这一事实，也不为描述符提供新完整性保护。

格式骨架不厚。头部声明算法（当前条目为 ChaCha20-Poly1305，即 RFC 8439），随后是派生所需的公钥集合与校验信息，密文区承载原始数据。对称选择 ChaCha20-Poly1305 的理由在脚注里写得直白：比特币核心已经在 BIP-324 等场景使用这条算法，实现熟悉度高，单遍完成加密加认证。

最关键的是密钥派生。加密密钥从描述符里全部公钥按字典序排序后送入 KDF 得出——排序固定消除参与人书写顺序带来的歧义；不掺任何私密因子，意味着“我有一把合法公钥”本身就是解密资格。推论值得慢慢咀嚼：解密权限的分布与描述符的访问结构天然同步，任何一个签名者能恢复这份元数据备份，但外人拿到密文时，既看不到内部结构也数不出共管人数。

与加密字库做对照能看得更清。对助记词做口令加密防的是“拿到种子的人再进一步”，它保护的东西本身就是私钥；而描述符文件不含种子，BIP-138 防的是隐私侧漏，不是资金侧漏——两个机制防不同的洞，不可互替。

常见误区四条。一，“密文放云端就绝对安全”：强度来自算法与密钥不可得，云侧泄露日志、版本错位、文件损坏都不在保护范围。二，“任何持钥人都能独占这份备份”：恰恰相反，任何一把合法公钥都够解密，独占要靠介质管理。三，“里面没私钥，丢了无所谓”：描述符决定派生地址，只有加密描述符丢了等于钱包图纸丢了，需要重建。四，把它与 keystore 文件混淆：后者加密私钥本体，前者加密元数据，文件形态与密钥来源完全不同。

快速问答。问：它能给多签用户做什么？答：把“N 个 M 共管、哪些公钥、什么路径”整包加密，云端与刻字店都看不到结构。问：轮换一位共管者后旧备份还能解吗？答：公钥集合变了，派生密钥随之改变，需要重导重加密。问：对普通单签用户价值大吗？答：中等，收益主要是把“备份文件本身”从敏感物降级为可寄存的密文。

一笔直觉账：明文描述符放云盘，相当于把家庭住址、门锁型号、住户人数和取钥匙方式一起拍照上传；BIP-138 把同一张照片封进只有持证钥匙人才能拆的袋子里——照片内容分毫未变，变化的只是它泄露给谁。

再补一层演练清单。判断一份元数据加密方案是否真的可用，最可靠的办法是做一次陌生设备恢复测试：在完全离线的干净环境里，只凭这份加密备份和一把公钥，能否重建出与原始钱包一致的下一个接收地址。测试通过，说明派生规则、排序约定与路径字段全都自洽；测试失败时优先检查公钥集合排序与版本字段，这两处是各家实现最容易出现口径差异的地方。演练频率不需要高，但每次软件大版本升级或共管结构变动后各做一次，能把“备份纸面上的正确”兑现成“事故当晚真的能恢复”。