關鍵要點

行動裝置證明生成速度提升逾 14 倍。

部分交易測試在 200 毫秒以下完成。

網路確認仍是另一個獨立流程。

錢包整合決定了誰能獲得這些改善。

延遲發生在 Zcash 看到付款之前

在一筆私密 Zcash 付款抵達網路之前，付款方的錢包必須選取可花費的票據（note）、準備交易、生成零知識證明並對結果簽名。證明生成佔了本地等待時間的大部分，因為它必須在揭露付款方、收款方或轉移金額的情況下，證明該筆付款是有效的。與透明付款相比，這個本地運算步驟歷來是遮蔽付款（shielded payments）的實際取捨之一，因為透明付款的錢包在廣播前所需的密碼學運算少得多。

Zakura 表示，其開源 Common 程式庫在部分測試中將該流程從超過三秒縮短至 200 毫秒以下。在該團隊的基準硬體上，行動裝置證明生成速度提升逾 14 倍，桌面端生成速度提升逾 5 倍。

這些結果來自 Zakura 自身的測試，而非獨立的錢包基準測試。實際效能將取決於裝置、作業系統、交易組成與錢包實作方式，因此較舊的手機可能無法重現標題中的數據。

200 毫秒的界線在哪裡

一筆 Zcash 付款仍須經過三個獨立階段：

建構（Construction）： 錢包在使用者裝置上建立交易並生成其隱私證明。Zakura Common 加快了這個階段。

廣播與確認（Broadcast and confirmation）： 錢包將完成的交易提交至 Zcash 節點。在礦工將其納入區塊之前，該交易仍處於未確認狀態。

結算信心（Settlement confidence）： 後續每個區塊都會增加一次確認，並降低因鏈重組而導致交易被逆轉的可能性。

Zcash 文件將首次確認定義為交易進入區塊的時間點。低於 200 毫秒的結果在廣播之前就結束了；區塊產出、記憶池（mempool）狀況以及收款方的確認政策，仍然決定付款何時被視為已結算。

效益延伸至發送按鈕之外

Zakura 還測量了影響交易處理、錢包同步與節點效能的三項運算的改善：

Sinsemilla 雜湊： 在 Zakura 的測試中速度快逾 21 倍。Zcash 在其遮蔽協定中使用此雜湊函數，因此更快的執行速度可減少部分密碼學運算負載。

試探解密（Trial decryption）： 快逾 1.5 倍。錢包在掃描區塊鏈時使用此流程，以識別屬於自己的遮蔽輸出（shielded outputs）。

zk-SNARK 驗證： 快 4 至 8 倍。節點使用驗證來檢查遮蔽證明，而不會得知其保護的資訊。

更快的試探解密可縮短錢包同步與帳戶恢復時間，而更低成本的驗證則可減少節點所需的工作。Zakura 也預期全節點的改善將支援更快的交易傳播與更少的孤兒區塊。

時機之所以重要，是因為更多 ZEC 正轉移至較新的遮蔽基礎設施。如先前報導，Ironwood 在啟用後不久便超越 Orchard，成為 Zcash 最大的遮蔽池。隨著遮蔽活動增加，緩慢的錢包建構與同步將成為更多使用者可能遇到的問題。

無需硬分叉也意味著不會自動推出

Zakura Common 改變了軟體執行現有密碼學工作的方式，而未改變 Zcash 的共識規則。這些程式庫產生的證明可被現有網路理解，讓錢包開發者無需等待礦工與節點啟動硬分叉即可使用。這種純軟體升級路徑是 Zcash 近期協定工作的特色，錢包與程式庫層級的最佳化可透過一般的應用程式更新觸及使用者，而無需協調的網路升級。

Common 儲存庫採用 MIT 與 Apache 2.0 授權條款提供。另一個 wallet-libraries 儲存庫則將錢包端元件連接至最佳化後的技術堆疊。

這種相容性消除了全網路部署的障礙，但每位錢包開發者在向使用者發布之前，仍必須審查、整合並測試該程式碼。保留現有證明技術堆疊的錢包將維持原有效能。

Zakura 表示，其即將推出的 1.3.0 版本將採用 Common。之後，焦點將轉向獨立行動錢包。它們的發布說明與實機測試將顯示此項改善是否能超越 Zakura 自家的軟體。

錢包採用現已成為瓶頸

Zakura 的基準測試顯示，遮蔽證明生成可以在不改變 Zcash 網路的情況下大幅加快。實際成果現在取決於既有錢包是否採用這些程式庫，以及獨立測試是否能在常見手機上重現這些效益。

同步與恢復時間也很重要。如果這些等待時間在錯誤率沒有上升的情況下降，Common 改善的將不只限於使用者按下「發送」的那一刻。

Zakura 已證明錢包端的延遲可以在不改變 Zcash 本身的情況下降低。剩下的問題是，有多少錢包開發者會將這份速度交到使用者手中。

本文 Zcash Wallet Upgrade Makes Private Payments Faster 最先刊登於 Coindoo。