Zcash 的地址家族里多了一个新面孔：以 tex 开头的字符串。它出自 2024 年 1 月创建、状态 Active 的 ZIP-320，标题很长，意思很短：定义一种“只能用透明地址的钱付给它”的收款地址。规范署名 Daira-Emma Hopwood 与 Kris Nuttycombe，致谢栏里的社区成员 Hanh，正是这个方案在讨论中最早的提出者。
故事从一封下架警告开始
规范把背景写得直接：2023 年 11 月，Zcash 社区收到币安通知——如果社区拿不出一个让交易所能够用链上信息辨认存款来源、必要时原路退回的机制，Zcash 面临下架风险。讨论中 Hanh 提出了钱包侧的解法：给透明 P2PKH 地址换一种新编码，让“把它当收款地址的人”自动约定只用透明资金向其付款。ZIP-320 把这套做法正式化。它同时设了三条设计目标：收款方可以确信付款是能被退回的；没升级、不认识这个格式的旧钱包不能把它错当别的类型、也不会不小心把屏蔽资金打进去；收款方除了换一种地址写法，不需要动任何基础设施。
编码：同一段哈希，第二种叫法
tex 地址不是新密钥。规范给出的解码路径是：对 Base58Check 解出的字节序列检查总长 22 字节、前两字节的地址前缀必须是 0x1C 0xB8，剩下的 20 字节就是验证密钥哈希；反过来，把这 20 字节用 BIP-350 定义的 Bech32m 编码、人可读前缀取 tex，就得到新地址。规范附的参考实现演示了从 t1Vmm……到 tex1……的完整互转。校验体系也各有来历：Base58Check 自带内嵌校验，Bech32m 自带纠错码，两条路各管各的输入检查。
钱包被规范要求做什么
ZIP-320 对“消费者”——钱包、交易所等——下了一组明确指令。付款时，遇到这种地址只能选择透明来源的资金构造输出；展示历史时，规范用 SHOULD 措辞建议钱包记住“哪个交易输出发给了 TEX 地址”，以便如实向用户展示这种形式，而不是它的 P2PKH 旧形式——并且接受从种子恢复时这个映射可能丢失的事实。新前缀的选取也有讲究：规范特意要求避开旧式透明派生可能已经生成的地址空间，防止和 BIP44 路线的既有地址相撞。
一个地址，两种形态
对用户来说最需要建立的心智模型是：tex 地址和你手里那串 t1 透明地址来自同一个密钥哈希，是同一把锁的两种刻法。差别只在“对方向你付款时是否被约束为透明来源”。当交易所给你 tex 形式的充值地址时，它其实同时能认出对应的 t1 形式；而老钱包遇到不认识的 tex 前缀会直接拒绝，这正是规范刻意设计的安全边界——宁可报错，不可错付。地址前缀这套思路在波卡与瑞波生态也各有版本：同一把公钥在不同链地址却不同：SS58 地址格式与前缀校验、交易所让你填的目的地标签是什么：XRP Destination Tag 与 X-address。
你该做的与不该做的
操作层面的清单很短：向交易所充值时按交易所给出的形态原样填写，不要自作主张换算成另一种形态再赌对方的校验；用新钱包给 tex 地址付款后，确认这笔支出动的是透明余额；旧版本钱包报“地址格式不支持”时，升级或改走它认识的形式，而不是绕过警告强行发送。涉及交易所的政策变化（例如当年币安的要求本身也可能调整），以交易所与官方规范的现行文本为准。隐私与合规的取舍因人而异，本文只讲机制，不构成投资建议。
换前缀不是换妆
最后提醒一个语义陷阱：tex 与 t1 是同一密钥哈希的两种文本形态，但这两种形态承载的约定不同——t1 只说“这是透明地址”，tex 额外说“请只用透明资金付我”。对方给你 tex 形式地址时，自作聪明地转成 t1 再转账，等于单方面撕掉约定；反过来把 t1 强塞给只支持 tex 校验的收款系统则会被拒。两种形态都合法，但按对方要求的形态原样使用，语义才是完整的。当年推动这件事的交易所要求属于外部政策，可能变化，动手前以交易所现行公告与钱包支持列表为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。