Zcash 的屏蔽池不是一次性建成的：Sprout、Sapling 之后，NU5 网络升级带来了第四个池子 Orchard。老读者可能还记得透明池与屏蔽池之间的资金搬家和nullifier 如何在屏蔽池里防双花，这篇要把镜头拉近一档：Orchard 到底把哪些东西改了，为什么官方在升级说明里强调它”把 Zcash 迁移到 Halo 证明系统、移除对可信设置的依赖”。
为什么要再加一个屏蔽池
每代屏蔽池对应一组密码学参数和一类隐私集合。把新池子放在重大网络升级时启用，是为了让货币基础的安全边界清晰可查——ZIP 224 的官方描述正是这个口径：NU5 引入新屏蔽池，其支出密钥与支付地址面向未来的可扩展性改进。对使用者来说，“新池子”不是多一个钱包余额分区那么简单，它意味着交易结构、证明系统和哈希承诺三件事同时换代。
支出和存入被装进同一个动作
Sapling 时代，一笔交易里的”花费”（Spend）和”新建票据”（Output）是两类不同的组件，各配各的证明。ZIP 224 把这两半合并成一个动作（Action）：一个 Action 包含一张被支出的票据和一张新创建的票据，暂时不用的那一半用哑元补齐。一笔 Orchard 交易携带一组 Action 的捆绑（bundle），整个捆绑只需要一份 Halo 2 证明来覆盖。交易越忙，捆绑里塞的动作越多，摊销到每个动作上的证明成本越低；交易很轻时，哑元机制保证格式仍然统一，实现不必为”只有支出""只有存入”维护特例。
底层换代：Halo 2 与免新仪式
官方页面明确写道，NU5 让 Zcash 转向 Halo 证明系统，去掉可信设置的需要。落到 Orchard 上，ZIP 224 写明它使用 Halo 2 证明系统与 PLONKish 算术化，取代此前的 Groth16 加 R1CS 组合——早期池子的电路参数来自专门的仪式，而这套新电路不再要求为它单独办一场。同一份文档也谨慎地补充：Halo 2 的递归证明能力这一版先不用，留给后续协议更新。
Sinsemilla：换掉承诺的锤子
Orchard 的非同态承诺改用 Sinsemilla 哈希，替换掉此前的博维-霍普伍德 Pedersen 承诺。这属于电路内部的基建：Sinsemilla 对 PLONKish 电路更友好，证明器算同样的事情更省。对普通用户，它不改变”屏蔽池里的金额被藏起来、靠 nullifier 防双花”的基本心智模型，改的是藏东西的方式和成本。
交易格式与统一地址：用户真正碰到的两层
配合新池子的是 ZIP 225 定义的第 5 版交易格式：序列化结构里给每个既有资金池划了边界清晰的区域，并新增承载 Orchard 元素的区域。这意味着同一笔交易可以同时挂上透明输入、旧池支出和 Orchard 动作，跨池合并从”多笔交易接力”变成”一笔交易办完”。地址侧则配合统一地址：一段编码里同时携带多个接收器，钱包按对方支持情况挑选走哪个池，细节可以看统一地址怎么选接收器。
哑元、规模与隐私集合
把支出和存入捆在一起还有个不那么显眼的好处：观察方很难从交易结构直接读出”这笔只花钱不存钱”还是”只存不花”，因为每个动作天生两半齐全、缺的一半由哑元补齐。同一池子里的票据数量积累得越多，单张票据被挑出来的难度越大，这也是每代池子都要重开隐私集合的原因——新池的票据从 NU5 之后重新计数，早期用户反而处在集合更小的旧池里，这正是资金搬家建议尽快进入新池的机制背景。至于防双花，ZIP 224 在动作层面同样定义了 nullifier，并给出了由票据密钥计算它的规则——观察者能确认”这张票据被花过一次”，但仍然看不到花它的是谁。
边界在哪里
Orchard 不改变链上公开的那部分：交易何时被打包、池间搬运的规模，观察者在节点视角仍然看得见；它也不意味着旧池消失，Sapling 余额不会因为升级自动搬家。交易所与钱包对新格式的支持进度取决于各自实现，充提行为以平台公告与钱包文档为准。涉及具体金额与费率时请以官方文档和链上数据核验，本文只是机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。