Loading...
本文镜像自Proof Street，一家报道隐私保护计算的独立刊物：ZK、FHE、MPC、TEE 和去中心化身份。最初于 2026 年 9 月 7 日以“Zcash在选择性披露方面已走了多远，以及还剩下什么”为题发布。经作者许可，作为Zcash Community Grant #339的一部分进行镜像。作者：Stephen Webber。
在Zcash中，查看密钥允许账户持有人向其选择的一方披露屏蔽交易历史。这些密钥已上线并由用户控制。开发者和政策倡导者仍在努力让它们服务于可从中受益的合规工作流程。
8 月 17 日，Zcash Community Grants 委员会开会审议了一项名为 Shielded Compliance Bridge 的提案。Deborah Olaboye 是一位开源贡献者，其工作包括 Ethereum 的 execution-specs 仓库；她已构建了一个概念验证，接收统一完整查看密钥，根据测试网上的索引器扫描紧凑区块，并在Zcash备注字段中携带“合规参考”，将一笔屏蔽转账关联至链下 Travel Rule 记录。她申请资助以完成该项目，但委员会拒绝了。
其理由是：合规集成取决于将使用它们的具体交易所或机构，没有可供构建的共同标准，并且在没有合作伙伴提出该工具需求的情况下，采用的可能性很低。同一次会议还以类似理由拒绝了其他提案，其中一项是“可编程选择性披露”虚拟机，另一项是隐私与信任架构框架，后者包含一张美国法律问题地图。
当然，这些决定并不意味着没有人想要这个。结合全年其他情况来看，恰恰相反。Binance 在 2024 年提出了协议层面的请求，并在当年获得了ZIP。Gemini 自 2020 年起就在监管监督下运行屏蔽提款。该生态系统于 6 月成立了一个华盛顿政策组织，并于 8 月成立了一个机构集成团队。委员会实际上所说的是，这一需求尚未被写成任何人可以据此构建的要求。
一个屏蔽的Zcash地址由消费密钥控制。从该密钥派生出的查看密钥可读取交易数据，但无法转移资金。完整查看密钥可查看账户的转入和转出交易；传入查看密钥只能查看收到的资金；传出查看密钥则让发送方重建其发送的内容。自ZIP 316起，这些密钥被打包为统一查看密钥：一个完整查看密钥和一个传入查看密钥，均限定于一个账户；账户是在ZIP 32下钱包密钥树中的一个位置。统一完整查看密钥打包了该账户所使用每个屏蔽资金池的各资金池组件，也包含账户的透明扩展公钥，因此共享一个此类密钥会同时暴露透明链和屏蔽历史。
从这个意义上说，查看密钥具有追溯性。它可解密账户自创建之时起的全部历史；一旦共享，除非将资金转移到新账户，否则无法撤回。不存在按单笔交易划分的查看密钥，也不存在有时间限制的查看密钥。ZODL的首席执行官 Josh Swihart 确认了这一点；该公司由协议原 ECC 工程团队于今年成立。他还提到，按单笔交易披露付款“尚未在任何地方实现”。
zcashd这一原始参考节点提供了两个 RPC 方法：z_getpaymentdisclosure和z_validatepaymentdisclosure，允许发送方向第三方证明一笔单独的付款。RPC 文档将它们标记为实验性功能：除非运营者设置实验性功能标志，否则它们会被禁用；并将其描述为正在实现“进行中的 Payment Disclosure ZIP”。该ZIP303现已标记为撤回，其后继版本ZIP 311仍是没有附带实现的草案。这些方法仅覆盖 Sprout 资金池，即最初于 2016 年推出的屏蔽资金池，且从未扩展至Sapling或Orchard；换言之，未扩展至承载所有现代屏蔽交易的资金池。zcashd本身已于 2026 年 7 月 18 日终止生命周期，这是 Ironwood 升级之前按计划进行的停止。Zebra——Zcash Foundation的共识节点——以及后继钱包Zallet都没有列出披露方法。对于关键资金池而言，按单笔交易披露仍只是设计意图。
这一意图仍然存在，但比 7 月时看起来更遥远。ZIP 231——备注捆绑包——是为其腾出空间的草案：Swihart 将备注捆绑包描述为经认证回复地址的最终基础，后者可作为付款证明；而依赖的草案经认证回复地址需要大于当前备注字段所能容纳的证明。备注捆绑包是一项交易格式变更，协调NU7持币人投票的五个组织于 8 月达成一致：格式变更不在NU7的范围内，而在后续升级的范围内。投票本身从 8 月 25 日持续至 9 月 14 日，将发行、费用政策、区块间隔和 Sprout 弃用交由持有人决定；披露并未列入选票。较早的路径ZIP 311不需要共识变更，但仍是没有实现、也没有Orchard覆盖范围的草案。
因此，当前交付的是账户范围的查看密钥——完整或仅传入——具有追溯性、不可撤销，并由账户持有人主动共享；而交易级披露仍在路线图上。
无论在Zcash还是其他任何地方，披露机制都可从以下维度定位：披露什么（范围）；向谁披露（被授权方）；授权何时生效及可追溯多远（时间）；是否可撤回（可撤销性）；以及由谁发起——数据主体还是权威机构（发起方式）。
合规制度是对这些维度的要求，架构则是在这些维度上的立场。Zcash的查看密钥在设计上具有广泛范围、由持有人选择被授权方、完全追溯、不可撤销、由用户发起的特点。按交易所和监管机构的实际应用，要求方通常倾向于限定在某项关系或某个期间内，授予指定机构或其分析供应商，自开户注册起持续生效，在关系终止时可撤销，并由机构作为服务条件发起。
这两种情况都被称作选择性披露。在凭证领域，选择性披露指从签名凭证中出示一部分属性而不披露其余属性，这正是SD-JWT、ISO mdoc 和 BBS+ 签名所旨在实现的功能。披露单位是属性，发生时点是出示时，持有人可针对每次交互作出决定。
在屏蔽支付领域，这一说法指向所选一方披露交易数据，其中单位是一个账户的历史，时点则是交出密钥的任何时候。
Swihart 表示，工程团队收到过的唯一协议层面合规请求来自 Binance；其在 2024 年 1 月要求为存款提供透明来源保证。团队的回应是ZIP 320——仅透明来源地址——而ZIP文本确实记载其起源“由 Binance 要求”。TEX 地址是一种短暂的透明中转地址，保证交易所收到来自透明来源的资金。它为交易所提供回传路径，却不会让交易所看到发送方的历史。协议为交易所作出的这项唯一适配，恰好披露了交易所要求的内容，仅此而已。
Swihart 认为，自Sapling升级以来，交易所没有技术理由不支持屏蔽交易：证明速度很快，交易所客户已在开户时完成身份识别，并且对于需要的情况已有强化尽职调查。从这个角度看，机制与合规工作流程之间的距离并非缺少一个基础原语，而实际上是缺少一次对话。
Divij Pandya 正在推进这场对话的另一端。他是Zcash旗下 Pretty Good Policy 的执行董事；该华盛顿政策组织于 6 月成立，是此前由 ECC 主导的一项倡议的延续。该组织的项目是让查看密钥披露在合规官可以引用的文件中被认可为可接受的合规机制。据他所知，尚无监管机构将查看密钥作为一种工具加以研究。PGPZ的范围自然是获得认可，而不是提供开发者指引。在有权威的人对这一工具作出裁定之前，工具无法依据某项要求进行定义，因此认可属于上游步骤。该组织的申报文件由 Paul Brigner 签署，他既是PGPZ的创始人，也是ZODL的首席政策与监管官；因此，政策和工程工作不仅共享一个主张，也共享一位主管。
7 月 21 日提交给众议院 FinCEN 监督小组委员会的书面陈述，将Zcash描述为具有“选择性披露能力，允许用户通过查看密钥，自愿与审计师、税务机关或合规官分享交易详情”，并提及与“选择性查看密钥”配对的零知识证明，以证明特定事实。向 FinCEN 备案提交的评论信FINCEN-2026-0101-0050，据 Pandya 所述，主张查看密钥和选择性披露应成为可接受的合规机制。他们向监管机构提出的开放问题是粒度问题：账户范围、全部历史的披露是否足以满足“有针对性的交易信息”，还是答案要等待ZIP 231。
在此问题解决前，合规团队面临着一项限制；匿名论坛发帖者 strahncryptography 在 Olaboye 提案的讨论中曾描述过：他们严格遵守规则，若没有监管机构或律师事务所的证明，无论密码学多么可靠，都不会采用一条未获认可的路径。任何将参考信息附加到交易的披露设计，只能证明最后一跳，而最后一跳可能正是存款人本人。查看密钥也有同样的限制。它揭示的是账户持有人的交易，而不是对手方资金的来源；后者才是制裁筛查所问的问题。
只要要求是由数据主体证明发生了什么，查看密钥就能满足标准，例如存款人选择说明的存款来源、自愿审计、税务申报、证明某笔特定付款已完成。这些都是用户发起、可追溯、一次性的披露。但如果要求是从开户起持续监控、针对账户持有人无法控制的对手方进行制裁筛查、限定于某个期间或某项关系，或在离开服务时撤销权限，那么它们便无法满足标准。
Gemini 自2020 年 9 月起接受向屏蔽地址提款；当时一位发言人将此归功于与监管机构持续进行的对话。它在 2025 年 11 月将这一支持扩展至Orchard资金池，并在 2026 年 7 月激活后两天扩展至 Ironwood 后的资金池。它接受从屏蔽地址发送至透明托管的存款。Kraken 的提款地址列表仅支持透明ZEC地址，Coinbase 同样仅支持透明地址，而 Binance 要求 TEX。尚无主要受监管交易所提供屏蔽托管、屏蔽存款地址，或可将客户查看密钥纳入其中的工作流程。
数据接入正在下一个层级构建。在本年 9 月审议中的持币人指导型追溯性资助轮次提案中，包括：ZecBooks——一款 Mac 记账工具，可导入仅查看密钥、分类备注，并为会计师导出限定范围的记录包，而不授予对钱包的持久访问权；ZecLedger——围绕统一完整查看密钥构建的只读成本基础和对账工具，已根据主网钱包测试；以及 seer-sync——一个链同步引擎，可接收查看密钥，使支付处理商或会计系统能够观察屏蔽活动，而无需持有消费密钥。它们都不是交易所工作流程，也都未获得监管机构的关注。每一项都是同一问题中面向会计师的那一半，由一两个人在没有合作伙伴提出需求的情况下构建；而 ZecBooks 的限定范围导出，正是在最常需要的第一个界面上运行的选择性披露：屏蔽用户与为其记账的人之间。
Zcash的开发者正在解决每一种隐私架构共有的问题。
在 Zama 的 confidential-EVM 设计中，访问控制列表决定哪些地址可请求解密密文，而由密钥管理运营者组成的门限网络按请求执行解密。这将被授权方这一维度从用户交出的密钥转变为合约记录的权限，并使发起方式可编程，因为合约可将授予审计师解密权作为使用条件。它并未使披露在合规官所指的意义上可撤销，因为已解密的密文仍然是已解密状态；它还以运营者诚实作为信任基础，替代了用户对密钥的保管。资产级审计师密钥——如 Solana 的 confidential transfer extension 和 Avalanche 的 encrypted ERC 设计——在代币层面固定了被授权方，因为发行者或指定审计师可以读取该资产的余额和转账。
Inco 发布了一个框架，用于预定义查看：访问权限在交易时固定于密钥材料中；与之相对的是可编程查看访问，其中查看权是可在之后授予、限定范围和撤回的合约状态。
查看密钥与合规工作流程之间究竟差了什么？
查看密钥披露的是账户持有人自己的历史。制裁筛查和持续监控询问的是对手方，即每笔交易另一端的资金从何而来；而这恰恰是屏蔽资金池存在的目的——将该信息隐藏起来。至今无人展示过一种设计，能够在不依赖透明账本或可信第三方的情况下回答对手方问题。
如果备注捆绑包在NU7之后的升级中落地，并且回复地址草案随之推进，那么PGPZ申报文件中的“有针对性的交易信息”将成为字面意义上的现实。这至少还要经历两次升级，而监管答案将按监管机构自己的时间表到来。
从为此努力构建的人数中，很容易看出需求。缺少的是隐私保护披露的固定要求。Zcash是一个生态系统，在这里，这项决定由工程师、倡导者、开发者、交易所和资助委员会公开协商；他们似乎同意目的地，却在争论步骤的先后顺序。独立开发者也在推进这项工作：他们没有等待要求被写下，便从会计层开始着手。
披露：本文获得了Zcash Community Grant的支持。ZCG未在发布前审阅或批准本文。