Zakura 已发布一项实验性实现，为 Zcash swap 地址提供独立的入向查看密钥，同时保留账户的花费权限。根据其 10 月 15 日候选版本，在正式地址发放之前，该密钥派生方案仍需接受审查。

一个退款地址可能暴露多笔 swap

通过 NEAR Intents 将 ZEC 进行 swap 需要一个用于退回未使用资金的地址。Zakura 的 Adam Tucker 在一份工程说明中表示，当存款登记时，这个屏蔽的退款地址会被记录在 NEAR 的公共区块链上，即使最终没有发生退款。swap 换入 ZEC 时也会公布接收地址。

这些地址可能看起来互不相关，但它们共享同一个入向查看密钥。因此，恢复该密钥可能泄露 swap 之外的收款记录。

所述攻击需要一台足够强大的未来量子计算机从暴露的地址中恢复密钥，然后才能识别与该密钥相关的入向付款，包括金额和备注。该提案针对的是未来的机密性风险，而非报告正在发生的攻击。而且由于这些地址记录在公共区块链上，今天留下的披露信息在功能足够强大的机器出现后，仍可能被用于此类分析——这就是业内常说的 “先窃取、后解密”（harvest now, decrypt later） 的长期暴露模式。

独立的查看密钥将保持花费账户完好无损

Zcash 将查看权限与花费权限区分开来。查看密钥的设计目的是让持有者可以共享其入向付款的只读访问权限——例如用于记账或审计——而不必放弃对资金的控制。其钱包密钥派生标准在 ZIP 32 中有所描述，支持从单个种子派生密钥和地址，使钱包能够管理多个地址，而无需为每个地址单独备份。

仅仅生成另一个地址并不一定会创建独立的入向查看密钥。Zakura 提议的更改在地址背后运作：如该实现的文档所述，它为每笔 swap 退款或入向 swap 派生一个独立的查看密钥。

该实现保留了账户的花费权限。用户可以使用同一个账户花费通过这些独立 swap 密钥收到的资金，避免将余额分散到多个账户带来的操作负担。

在当前的共享密钥模型下，恢复一个密钥可能暴露多个地址的入向付款。而使用独立的 swap 密钥时，恢复某个 swap 的查看密钥只会暴露与该密钥相关的收款记录，而不会自动打开其他不相关的入向付款。查看钥本身并不授权花费。其保护目标更为有限：限制单个泄露密钥可能泄露的支付历史。

恢复过程必须在不暴露所有权的情况下找到付款

独立密钥在钱包恢复时会带来发现问题。从种子重新生成密钥并不能告诉钱包哪些密钥收到过付款。用每一个 swap 密钥对整个交易历史进行逐一尝试，会随着 swap 数量增加而加重恢复工作量。

出向 swap 提供了留下恢复记录的位置。所提议的实现将一条加密备忘录放入用户出资交易的 note 中。该备忘录记录了用于派生退款密钥的索引。在恢复过程中，钱包可以找回该索引并重建对应的密钥和地址。

入向 swap 则需要另一种方法，因为 Zcash 钱包并未创建可用于留下该备忘录的出资交易。该设计改为按顺序检查确定性派生的地址，并利用已付款或已向 swap 提供方披露的地址记录来确定发现过程需要持续到何处为止。

为了定位付款，该接收方发现系统使用由钱包在本地检查的公共过滤器。可能出现匹配时，会发起一次私有信息检索（PIR）请求，在不向服务器发送包含地址的可读查询的情况下识别相关交易。

随后，钱包可以使用对应的查看密钥解密该付款。这避免了让每个恢复的密钥对整条链执行单独搜索。

私有查询还可以防止一串可读的查找请求暴露多个地址属于同一个钱包。否则，服务器可能先后收到针对地址 A、B、C 的请求，并将它们关联到同一个钱包，从而破坏新密钥所建立的隔离效果。

审查和钱包支持尚未完成

该实验性代码并不能证明钱包已为普通用户启用该功能。密码学审查尚未完成，且该实现规定，在一次性密钥为硬件账户启用之前，硬件签名器需要通过固件认证。

Zakura 的工程文章预计，未来几周内该功能将集成到兼容的软件钱包中，包括 Vizor。这只是开发时间的估计，并非确定的发布日期。

这项工作与 1 月份计划的 Zcash 支付保护措施是分开的，后者涉及支付授权。而 swap 提案涉及的是屏蔽入向支付历史的隐私。

新的密钥派生也无法删除已经公开记录的地址。隔离未来的 swap 密钥不会抹去与现有共享查看密钥相关的既往披露。

剩余的交付工作很明确：审查该派生方案、集成付款发现和恢复功能，并对支持的签名器进行认证。在这些步骤完成之前，用户才能在正式发布的钱包中依赖所提议的隔离机制。

本文仅供信息参考。所提议的功能尚属实验性质，正式使用前仍需进一步审查。

本文最初发表于 Coindoo。