一句话就能说清这份草案想解决的问题：助记词能带回你的余额，带不回你给每笔交易写的备注。钱包的主数据源当然是链，从链上它能发现哪些 note 属于自己、判断它们是否已被花掉、构建花费所需的见证、还原链上 memo 字段里的内容。但钱包在日常使用中还生产了大量链下元数据，提案列了三类：给交易写的本地注解、地址与用户能读懂的收款人名称之间的映射、以及决定要发多少 ZEC 时所用的兑其他货币汇率。设备丢失或被抹掉、用户从助记词恢复钱包时，如果这些元数据没有存到别处，就会全部消失。
为什么不能直接交给手机云备份
直觉方案是让系统备份去存这些文件，用户对手机里的其他数据也确实是这么预期的，登录同一个账户账号就能找回。提案指出的障碍是这一类元数据格外敏感：地址和收款人姓名的对应关系，本身就是不想被明文放进设备常规备份里的东西。另一条直觉方案是干脆写进链上 memo，但链上数据无法修改，把它当可反复更新的元数据存储并不合适。提案因此给自己定了三条硬性需求：用户不该为此更新已有的秘密备份；对只导入了完整查看密钥、自己并不掌握支出权限的账户，也要能存元数据；密钥树必须留出扩展余地。
做法是从同一颗种子再长一棵树
ZIP-325 注册了一棵 ZIP-32 定义的注册密钥派生树：上下文串取 MetadataKeys，ZIP 编号取 325。落到路径记号上，账户元数据密钥是 m_metadata / 325' / coin_type' / account'，和账户本身用同一颗种子、同一个币种与账户序号对齐，因而无需用户再备份任何新秘密。再往下分两支：0' 子树是账户级的内在元数据密钥，用于和这个账户自身绑定的元数据；1' 子树是账户级的外部元数据密钥，用于给导入的统一完整查看密钥存元数据。规范还划了一条纪律：树里非叶子的密钥不得直接拿去加密元数据，加密用的密钥必须是叶子，唯一例外是私用密钥那一支，允许从私用叶子继续派生。
查看密钥会变，域分离怎么办
外部密钥那一支还有个不显然的难点：统一完整查看密钥的内容本身会变，可能新增偏好更高的完整查看密钥项，也可能移除被弃用的项，谁也不能保证备份生成时和恢复时看到的集合一模一样。提案的处理办法是拿查看密钥自身提供域分离——取统一地址原始编码里偏好最高的那一项作为域，再派生出导入查看密钥的元数据密钥，路径写作 ... / 1' / (0', FVKTypedItem)。用法上，加密这类操作应当用最高偏好项对应的密钥树；解密则按偏好顺序逐棵树尝试，直到能解出元数据为止，如果最终是靠某个较低偏好项解出来的，钱包应当把元数据用最高偏好项重新加密一遍回写，把备份更新上来。
私用槽位与“截至撰写时还没有标准协议”
除了预留的未来区间，草案还留了一个特殊的私用槽：在内在元数据密钥或导入查看密钥的子树里，取子号 0x7FFFFFFF（也就是最大合法硬化子号），配上一个全局唯一、最长 252 字节的私用主题串，就能派生一只不等生态协调、也不保证互相兼容的密钥。规范同时把风险写明了：主题串碰撞、由此可能引来的跨协议攻击分析，责任在钱包开发者自己身上；不愿意吃这个风险的，应当去提标准化的元数据协议。截至草案撰写时，已标准化的元数据协议数量是一个也没有，后续新增要靠写 2000 系列 ZIP 来更新这份草案。原文还顺手举了一个反面例子：有钱包直接拿 metadata 当私用主题，既没带钱包前缀也没带版本号。
这份草案的当前状态
必须把状态讲清楚：ZIP-325 的状态是草案，起草日期为 2025 年 2 月 18 日，讨论挂在 zips 仓库的议题上，原文给出的参考实现是安卓钱包 SDK 的一个合并请求，而不是所有钱包的共同现状。所以“我的钱包恢复后没有把备注名带回来”并不违反这份草案，草案描述的是可派生加密密钥的钥匙树，不是强制所有钱包自动同步元数据的能力。真正会因它改变的是备份策略的可能性：只要元数据用这棵树里的密钥加密过，用户仍然只需要备份那一句助记词。
用户现在能做什么
把这份草案当背景知识，实际操作上仍然要靠笨办法。第一，重要的收款人映射和用途标签定期导出，存进自己保管的加密介质，恢复演练时按比特币助记词备份怎么做才可靠？抄写、恢复演练与保管的完整清单里那套核对流程走一遍，看备注是否还在。第二，把备注当线索不当账本，到账金额与状态以链上记录和链上转账后对方没收到？从广播、确认到钱包显示的五步排查那种排查顺序为准，别拿标签替代流水。第三，比特币世界给钱包备份加注释字段的老办法在描述符也能带便签：BIP-393 给钱包备份加注释字段里已经讲过，思路是一致的：把可读注解和密钥分开管，恢复时才知道哪些东西本来就要自己带回来。本文不涉及价格判断，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。