Zakura 已發布一項實驗性實作，為 Zcash 兌換地址提供獨立的入帳查看金鑰，同時保留帳戶的支出權限。根據其 10 月 15 日的候選版本，該金鑰推導在正式地址發布之前仍需經過審查。

一個退款地址可能暴露多筆兌換

透過 NEAR Intents 兌換 ZEC 需要一個用於退回未使用資金的地址。Zakura 的 Adam Tucker 在一份工程說明中指出，當存款登記時，這個受屏蔽的退款地址會被記錄在 NEAR 的公開區塊鏈上，即使最終沒有發生退款。兌換成 ZEC 時也會公布收款地址。

這些地址看似互不相關，卻可能共享同一個入帳查看金鑰。因此，一旦該金鑰被還原，可能暴露兌換本身以外的收款紀錄。

文中所述的攻擊需要未來具備足夠能力的量子電腦，才能從暴露的地址還原金鑰。屆時它便能識別與該金鑰相關的入帳付款，包括金額與備註。該提案針對的是未來的機密性風險，而非報告正在發生的攻擊。而且由於這些地址已被記錄在公開區塊鏈上，今天暴露的資料在未來出現具備能力的機器時，仍可用於此類分析——這正是業界常說的「先竊取、後解密」（harvest now, decrypt later）的長期暴露模式。

獨立的查看金鑰可支出帳戶完整

Zcash 將查看權限與支出權限區分開來。查看金鑰的設計目的在於讓持有人可分享其入帳付款的唯讀存取權——例如用於記帳或審計——而不放棄對資金的控制。其錢包金鑰推導標準詳見 ZIP 32，支援從單一種子碼推導金鑰與地址，讓錢包能管理多個地址，而無需為每個地址分別備份。

單純產生新地址並不一定會建立獨立的入帳查看金鑰。Zakura 提出的變更運作在地址背後：它為每筆兌換退款或入帳兌換推導一個獨立的查看金鑰，詳見實作文件。

該實作保留了帳戶的支出權限。使用者可以直接從同一帳戶動用透過這些獨立兌換金鑰收到的資金，避免將餘額分散到多個帳戶的操作負擔。

在目前的共享金鑰模式下，還原一個金鑰可能暴露多個地址的入帳付款。而在獨立兌換金鑰的機制下，還原某一筆兌換的查看金鑰只會暴露與該金鑰相關的收款紀錄，不會自動開啟其他不相關的入帳付款。查看金鑰本身並不授權支出。其預期的保護範圍較為限縮：限制單一被入侵金鑰所能揭露的支付歷史。

恢復必須在不暴露所有權的情況下找到付款

獨立金鑰在錢包恢復時會產生一個尋找問題。從種子碼重新產生金鑰時，錢包並不知道哪些金鑰曾收到付款。若對整個交易歷史逐一嘗試每個兌換金鑰，兌換次數越多，恢復工作量就越大。

對外兌換提供了留下恢復紀錄的位置。該建議實作會在使用者出金交易的備註中寫入一則加密備註，記錄用於推導退款金鑰的索引。恢復時，錢包可以取回該索引，並重建對應的金鑰與地址。

入帳兌換則需要另一種方式，因為 Zcash 錢包並未建立可以留下該備註的出金交易。此設計改為依序檢查確定性推導的地址，並利用已付款或已向兌換服務商揭露的地址紀錄，判斷搜尋需要進行到哪裡。

為定位付款，該收款方發現系統使用錢包在本機檢查的公開過濾器。若發現可能的相符結果，便會發出私密資訊檢索請求（PIR），在不向伺服器送出可讀、指名地址的查詢的情況下，識別相關交易。

隨後錢包即可用對應的查看金鑰解密該付款。這避免了讓每個還原的金鑰對整條鏈進行個別搜尋。

私密查詢也能防止一系列可讀的查詢請求暴露多個地址同屬一個錢包。否則，伺服器可能會先後收到地址 A、B、C 的請求，並將它們關聯到同一個錢包，從而削弱新金鑰所建立的部分隔離效果。

審查與錢包支援仍未完成

該實驗性程式碼並不代表錢包已為一般使用者啟用此功能。密碼學審查仍未完成，且該實作明確指出，硬體簽署器必須先通過韌體認證，一次性金鑰才能在硬體帳戶上啟用。

Zakura 的工程文章預期在未來幾週內整合至相容的軟體錢包，包括 Vizor。這僅是開發時程估計，並非確定的發布日期。

這項工作與一月計劃中的 Zcash 付款保護措施是分開的，後者涉及付款授權。本兌換提案則關注受屏蔽的入帳付款歷史的隱私。

新的金鑰推導也無法移除已被公開記錄的地址。隔離未來的兌換金鑰，也無法抹除與現有共享查看金鑰相關的先前暴露紀錄。

剩餘的交付工作相當明確：審查金鑰推導、整合付款發現與恢復功能，並為支援的簽署器完成認證。這些步驟必須全部完成，使用者才能在正式發布的錢包中依賴所提出的隔離機制。

本文僅供資訊參考。所提議的功能仍屬實驗性質，正式使用前需要進一步審查。

本文最初發表於 Coindoo。