屏蔽冷签名
核心理念： 伴侣钱包可以看到构建和监控一笔屏蔽交易所需的一切信息。只有硬件钱包持有授权支出的权限。这种分离正是屏蔽冷签名的全部意义。
在 Zcash 中进行屏蔽涉及将资金从公开、透明的地址转入私密、屏蔽的地址，并使用 Zcash 的隐私功能隐藏交易详情。
当你屏蔽 ZEC 时会发生什么变化？
对于一笔透明的 Zcash 交易，以下信息：
都可以在 blockchain 上被观察到。
当你屏蔽 ZEC 时，你的资金会转入一个私密资金池（例如 Ironwood）。blockchain 可以验证一笔交易是否有效，而无需披露你的私密交易详情。自 2026 年 7 月 28 日的 NU6.3 升级以来，新屏蔽的资金会进入 Ironwood 资金池，因为较旧的 Orchard 资金池不再接受新存款，但仍允许提款。
屏蔽交易的组成部分
1. Note（屏蔽余额记录）
Note 是代表用户拥有的一笔未花费 ZEC 数额的私密加密记录。
与余额以明文列出的公开 blockchain 不同，屏蔽 note 会加密数值和所有权详情，使链上观察者无法看到资金归谁所有。
发起交易时，伴侣钱包会扫描账本，识别用户未花费的 note，并选择要花费哪些 note。
2. Nullifier（双重支付检测机制）
由于 note 的详情对公开账本隐藏，网络需要一种机制来检测双重支付，同时不泄露正在花费的是哪一笔 note。
Nullifier 是从特定 note 派生出的唯一加密标记。当一笔 note 被花费时，其 nullifier 会发布到 blockchain 上。
网络会验证该 nullifier 是否先前已被记录。如果未被记录，则该笔支出可以被接受。关键在于，外部观察者无法利用 nullifier 确定它来自哪一笔具体 note。
伴侣钱包会在组装交易数据时派生并构建相应的 nullifier。
密钥
密钥是控制你资金访问权、并让钱包能够执行接收、查看和花费 ZEC 等操作的加密信息。
一个钱包持有多种不同密钥，每种密钥承担不同用途，就像同一账户可能为读取权限和写入权限分别设置凭据一样。
密钥是伴侣钱包与硬件钱包之间关系的核心，因为不同密钥具有不同用途，并且其中只有一种必须始终妥善锁存。
重要的是，每个屏蔽资金池都会将其密钥构建为派生树，箭头从一个组件指向可从其派生出的内容。希望接收屏蔽付款的用户必须拥有屏蔽付款地址，该地址由支出密钥生成。
密钥层级
1. 支出密钥
这是安全敏感性最高的密钥。它赋予加密层面的能力，以授权支出 ZEC。
本报告其他地方提到“硬件钱包持有密钥”时，所指的就是这一密钥。
在冷签名架构中，支出密钥保留在硬件钱包内部，绝不会暴露给伴侣钱包。伴侣钱包根本不应需要持有该密钥。
在 Sapling 和 Orchard 中，密钥层级都从根支出密钥派生出支出授权和查看能力这两个不同分支：
- Sapling： 扩展支出密钥（𝑎𝑠𝑘,𝑛𝑠𝑘,𝑜𝑣𝑘）派生证明授权密钥（𝑎𝑘,𝑛𝑠𝑘）和完整查看密钥（𝑎𝑘,𝑛𝑘,𝑜𝑣𝑘），后者进一步产生传入查看密钥（𝑖𝑣𝑘）和多样化地址。
- Orchard： 根支出密钥（𝑠𝑘）直接分支为支出授权密钥（𝑎𝑠𝑘）和完整查看密钥（𝑎𝑘,𝑛𝑘,𝑟𝑖𝑣𝑘）。
这种结构性分离为硬件密钥隔离提供了正式的加密基础：钱包将查看分支（UFVK）导出至主机计算机，以进行余额同步和交易构建，同时将支出授权分支永久锁定在设备上。
密钥派生严格单向进行。这意味着无法反向利用查看密钥重建支出授权。加密不可逆性使导出 Unified Full Viewing Key（UFVK）是安全的，因为它授予完整的钱包可见性，而不会暴露设备上的支出秘密。
2. 查看密钥
Zcash 将查看屏蔽活动的能力与花费它的能力分开。查看密钥允许钱包或其他获得授权的一方查看屏蔽交易信息，而不会授予支出权限。
- Full Viewing Key（FVK），封装为 Unified Full Viewing Key（UFVK）： 它有意从支出密钥派生，使软件能够检测和解密钱包的屏蔽活动，从而识别交易。它也能计算余额，但无法授权支出。最准确的描述是，它是支出密钥的一个隐私性较低的派生物，而非种子的较弱副本。
Full Viewing Key（FVK）在维持严格安全隔离的同时，提供完整的只读可见性。通过解密传入和传出的 note 密文（借助其传出查看密钥组件），仅有 FVK 的伴侣钱包可以呈现完整、带标签的交易历史，而非仅显示持续变化的余额。
多个不可关联的多样化付款地址共享同一个 FVK 和传入查看密钥（IVK），因此可以无限生成地址，而不会增加 blockchain 扫描开销。
这种功能分离构成了冷签名工作流程的基础。所有持续的链扫描、历史追踪和地址管理都被卸载至主机软件，而支出权限仍隔离在硬件设备上。
关键区别：UFVK 与支出密钥
UFVK 可以共享。支出密钥必须留在硬件钱包中。
伴侣钱包使用查看密钥监控钱包、检测传入资金、识别 note，并协助准备交易。它不持有授权支出所需的私钥。
如前所述，密钥分离是冷签名架构的基础。
伴侣钱包无需控制资金，便可完成准备交易所需的大部分工作。硬件钱包只需接收准备好的交易并执行最终签名操作。
硬件钱包制造商无需自行发明这种分离机制。Zcash 的密钥设计已在协议层面将查看能力与支出权限分离，制造商只需在这一既有结构之上构建其签名和导出功能。该协议允许从支出密钥派生出屏蔽地址或完整查看密钥等信息，而支出密钥本身仍保持私密，这使得 Ledger、Keystone 和 Hito 等硬件钱包能够向伴侣软件提供其所需的查看信息，同时绝不暴露可花费资金的私钥。
伴侣钱包实际如何使用密钥信息
使用查看密钥材料，伴侣钱包可以：
- 识别你的资金和 note
- 确定哪些 note 可以花费
- 派生或识别相关地址
- 构建交易
- 生成或协调所需证明
- 准备待签名交易
需要构建交易并不等于需要私有支出密钥。这样的解耦是硬件钱包集成背后的核心安全理念之一。
屏蔽交易构建与授权
以下是创建和授权交易涉及的过程。简而言之，这些过程就是钱包实际如何使用这些数据来转账：
交易构建（组装屏蔽交易）
交易构建是根据用户预期付款组装创建有效 Zcash 交易所需信息的过程。
交易构建过程会将选定的 note、接收方、金额、手续费、nullifier 以及其他所需交易数据组合成交易结构。对于屏蔽交易，它还会准备生成必要零知识证明和签名所需的信息。
伴侣钱包通常执行这一阶段。它会：
- 选择要花费的 note
- 确定交易的输入和输出
- 计算必要的数值
- 准备之后将被证明和签名的交易数据。
在冷签名设置中，生成的交易数据可以封装为一个 PCZT，并传递给硬件钱包进行安全关键的签名步骤。
证明（证明协议有效性）
证明是指生成零知识证明（例如 Halo 2 或 Groth16），以证明交易遵循 Zcash 协议规则。
该证明帮助网络保证：
- 支出用户有权花费这些 note
- 这些 note 确实存在
- 对应的 nullifier 是唯一的
- 输入总额等于输出总额加手续费。
它在不泄露任何底层私密详情的情况下完成所有这些验证。
证明生成的计算强度很高。将这一责任卸载至伴侣设备可防止硬件钱包卡顿或耗尽内存。
签名（授权支出）
签名与证明在根本上不同。数字签名是由私钥持有者生成的明确授权凭证。
零知识证明验证交易有效性，而数字签名证明支出权限。签名证明真正的所有者批准了特定转账参数。
签名只需要极少的计算能力，因此非常适合由硬件钱包执行。
什么是屏蔽冷签名？
屏蔽冷签名是一种授权 Zcash 屏蔽交易的方法，同时将私有支出密钥与连接互联网的伴侣钱包隔离。交易可以在在线计算机上构建和准备，而单独的硬件钱包保持离线或以其他方式隔离，并使用其受保护的密钥来授权该交易。
该过程可简化为：
伴侣钱包将结构化交易参数发送至硬件设备，设备在内部对载荷进行签名，且绝不将私有支出密钥释放给主机。
伴侣钱包与硬件钱包
屏蔽交易可以同时涉及伴侣钱包和硬件钱包，各自承担不同功能。
伴侣钱包
什么是伴侣钱包？
伴侣钱包运行于计算机或移动设备上，并执行创建交易所涉及的大部分任务，例如：
- 选择要花费的 note
- 构建交易
- 计算必要的交易数据
- 协调生成所需的零知识证明。
为什么伴侣钱包有用？
伴侣钱包处理交易创建过程，但如果计算机感染恶意软件，攻击者可能能够：
- 看到你正在做什么，
- 修改未签名交易，
- 尝试诱骗你批准某些内容。
伴侣钱包无需访问存储在硬件钱包中的私钥，因此它可以处理交易构建及其他计算任务，而硬件钱包则为私钥提供安全边界。
硬件钱包
硬件钱包是一种离线实体设备，可将你的私钥与已连接的手机或计算机隔离，如同加密资产的安全金库。
为什么硬件钱包有用？
如果你的计算机感染恶意软件，攻击者可能能够：
- 看到你正在做什么，
- 修改未签名交易，
- 尝试诱骗你批准某些内容。
私钥无法被轻易从硬件钱包中提取，因此该设备可以充当安全边界。
伴侣钱包与硬件钱包能力对比图
这两种钱包之间的分离对于屏蔽交易尤为重要，因为屏蔽交易比透明交易更复杂，涉及屏蔽 note、nullifier、承诺、零知识证明和交易签名等组件。
让硬件钱包执行每一项计算操作并不现实。相反，伴侣钱包准备交易并向硬件钱包提供签名所需的信息，而私有支出密钥则始终隔离在硬件设备内。
密钥隔离
密钥隔离意味着，能够授权支出的私钥绝不会离开硬件钱包。配套钱包可以准备交易；但无法对其签名。
密钥隔离指将授权交易所需的私钥与配套钱包及其运行设备分离。在屏蔽冷签名设置中，配套钱包可以构建交易并协调所需的证明，而硬件钱包则让敏感的私钥保持隔离。
如果配套电脑或手机遭到入侵，攻击者或许能够在交易签名之前与其交互，但理想情况下无法从硬件钱包中提取私钥。因此，密钥仍处于硬件设备的安全边界内。
这种分离使配套钱包能够执行交易构建和计算任务，而无需让它直接访问授权交易所需的密钥材料。
需要明确的关键区别是，“viewing key”并不意味着应用程序获得了种子的弱化版本。
在 Zcash 中，Full Viewing Key（FVK/UFVK）是特意从支出密钥派生而来，它使持有者能够检测并解密相关的屏蔽活动，但不能授权支出。FVK 是支出密钥的保密性较低的派生物。
一个重要的隐私注意事项：
因此，应该知道的是，应用程序仅凭 UFVK 无法窃取资金，但它可以看到钱包的私密屏蔽活动。
这就是为什么更准确的描述是，配套应用程序拥有查看权限，而不只是说它拥有“公开信息”。
表达整个理念最简单的方式是：配套钱包获得了足以了解钱包正在发生什么的密钥材料，但没有获得足以授权钱包资金发生什么的密钥材料。不过，硬件钱包会保持支出权限隔离，并且仅在用户批准交易时使用它。
这就是这些屏蔽 Zcash 硬件钱包设计背后的核心密钥隔离模型，也是即将介绍的 Ledger、Keystone 和 Hito 中逐个实现所采用的同一模型。
PCZT
PCZT 代表部分创建的 Zcash 交易。它是承载 Zcash 交易及从一个阶段完成到另一个阶段所需信息的软件包。
它是交易仍在构建时用于 Zcash 交易的标准化格式。它让不同参与者或设备能够执行交易创建流程的不同部分，并在它们之间传递部分完成的交易。
在像 Zcash 这样的零知识加密货币协议中，构建交易比为简单公开转账签名复杂得多。屏蔽交易需要计算密集型的零知识证明，例如使用 Halo 2 或 Groth16 生成的证明。因此，硬件钱包等低功耗设备可能缺乏处理整个交易工作流程所需的内存和处理能力。
PCZT 的引入解决了屏蔽加密架构中的若干核心挑战。PCZT 是一种标准化的中间数据格式，它将交易创建拆分为模块化、相互独立的角色。它允许性能强大的配套电脑处理交易组装和证明生成，同时将离线硬件钱包严格限制为授权和签名。
硬件与冷存储限制
虽然硬件钱包为保护私有支出密钥提供了安全环境，但与配套电脑相比，它们通常拥有有限的 RAM、计算能力和数据传输能力。这些限制使其无法实际执行计算密集型的零知识证明生成，也无法维护交易构建过程中所需的完整交易状态。
因此，配套钱包可以处理计算需求高的任务，而硬件钱包则专注于使用其受保护支出密钥授权交易这一安全关键操作。
这让人不禁疑惑：如果设备受到如此多的限制，它又如何完成足够的验证以值得信赖？
简单来说，硬件钱包不能接受配套电脑提供的任意值并对其签名。它需要足够的信息来确定所签署的值对应于用户意图授权的交易。这造成了一种艰难的平衡，因为设备必须进行足够的解析和验证来保护签名流程，同时又要在内存、计算能力、固件大小和实现复杂度的严格限制内运行。
Ledger 的 Orchard PCZT 处理就是这一挑战的一个例子，这表明依赖专用电路的解析可以使受限设备上的实现更易于管理，但当支持的交易结构或电路演进时，也可能需要更新固件。
两项持续进行的工作展示了针对同一限制的不同应对方案。
一项关于适用于开源硬件钱包架构和普通电脑的全恒定时间证明流水线的研究提案，在 Grant #423 中被提出。其目标是研究可在 C 或 Rust 等环境中安全实现的密码学基础设施，同时降低屏蔽 Zcash 支持的复杂性和维护负担。
不过，另一种方法由提议的 Zcash SeedSigner 代表，它是一个由廉价、易获得组件构建的开源隔离签名器。其拟议工作流程将配套电脑与签名设备分开，通过空气隔离传递 PCZT，以供设备上验证和签名。
https://forum.zcashcommunity.com/t/grant-application-research-on-a-fully-constant-time-proving-pipeline-for-open-source-hardware-wallet-architectures-reusable-for-standard-computers/57555
这些方法共同说明了屏蔽硬件钱包背后更广泛的工程挑战：交易构建和证明可以在安全关键设备之外进行，但签名器仍必须拥有足够的信息和验证能力，以安全地授权最终交易。
PCZT 实现拆分架构
部分创建的 Zcash 交易（PCZT）标准，是连接配套钱包与硬件钱包的正式数据结构。
配套钱包能够自行处理票据选择、计算 nullifier，并生成零知识证明。这是可能的，因为这些步骤所需的信息，包括用于派生 nullifier 的密钥，来自 viewing key，而非与支出权限绑定的任何内容。随后，配套钱包将这些元素打包进 PCZT 容器。
PCZT 会交给硬件钱包，硬件钱包读取交易上下文（例如金额和收款人地址），使用其受保护的支出密钥应用签名，并将更新后的 PCZT 交还给配套设备。
这种设计建立了严格的安全边界：强大的主机硬件可以执行复杂的零知识计算，而无需访问支出密钥；低功耗冷存储设备则可以强制保障资金安全，而无需计算繁重的密码学操作。
证明者的隐私妥协
尽管将零知识证明生成委托给配套钱包或其他证明者可使支出密钥保持隔离，但这仍要求证明者访问敏感交易信息，例如票据价值、收款人地址和承诺。
PCZT 通过确保可为证明提供这些信息，而无需传递授权所需的私有支出密钥，维持了这种架构分离。
这保证了证明权限与支出权限相分离。证明者可以执行计算密集型证明生成，而不会获得支出用户资金的密码学权限。
PCZT 互操作性
随着 PCZT 成为 Zcash 硬件钱包、多重签名和空气隔离签名工作流程的重要组成部分，独立实现之间的互操作性变得日益重要。
AngryDavee 于 2026 年 6 月提出的一项提案指出，PCZT 实现已存在于包括 Ledger、Keystone、Hito、OneKey 以及 librustzcash 中的参考实现等项目中。然而，该提案发现缺少用于确认这些实现一致解释 PCZT 的共享测试。
拟议解决方案是一个开源互操作性测试套件，其中包含规范的 PCZT 测试向量，以及涵盖完整 create → sign → finalize 工作流程的跨实现测试。它还提议测试诸如 Combiner 等角色边界，在交易完成之前，来自不同签名者的部分签名信息可在其中合并。
这与硬件钱包尤其相关，因为 PCZT 允许交易构建与签名分离：配套钱包可以构建交易并准备 PCZT，而硬件设备接收所需的签名信息并执行安全关键的签名操作。
该提案未获实施，因为 Zcash Community Grants 在审查提案并考虑社区反馈后决定不再推进该资助。因此，拟议的跨实现测试套件并未通过这项资助开发。它因此是对已发现的 PCZT 互操作性挑战的拟议回应，而不是当前已在 Zcash 中存在的标准。
https://forum.zcashcommunity.com/t/pczt-interoperability-test-suite-feedback-before-at-grant-submission/55931
PCZT 的生命周期
| # | 阶段 | 描述 |
|---|
| 1 | 创建者 | 使用全局交易元数据初始化 PCZT，包括交易版本、共识分支 ID 和池标志。 |
| 2 | 构建者 | 以透明、Sapling、Orchard 或 Ironwood 池中的预期输入和输出填充交易。 |
| 3 | IO 最终处理器 | 声明输入和输出集合完整，计算绑定签名密钥，并在需要时签署虚拟支出。 |
| 4 | 更新者 | 为后续参与者附加必要的上下文数据，例如完整 viewing key、锚点和 Merkle 见证。 |
| 5 | 证明者和签名者 | 执行零知识证明生成和密码学签名。在现代 PCZT 版本中，这两项任务完全独立，可以顺序或并行进行。 |
| 6 | 合并器 | 如果不同设备同时处理同一交易的不同方面，则确定性地合并多个 PCZT 实例。合并规则要求严格的冲突解决机制，以防止意外数据丢失。 |
| 7 | 支出最终处理器和提取器 | 验证所有必需的密码学元素，去除中间上下文元数据，并生成可供网络广播的最终 Zcash 交易。 |
现实世界的硬件钱包实现
一览
| 设备 | 配套设备接收的内容 | 留在设备上的内容 | 传输方式 |
|---|
| Ledger | UFVK / Orchard FVK、地址 | 支出权限 | USB / BLE |
| Keystone | UFVK + Unified Address | 种子 / 支出密钥 | QR（空气隔离） |
| Hito | UFVK、Unified Address、种子指纹 | 种子和私有支出密钥 | QR / 本地 |
已经开发了多种硬件钱包实现，以探索如何在保持敏感支出密钥与配套钱包隔离的同时支持 Zcash 屏蔽交易。Ledger、Keystone 和 Hito 代表了将基于硬件的密钥保护与 Zcash 交易工作流程集成的不同方法。
要了解它们如何保护屏蔽资金，重要的是区分支出密钥与 viewing key。在这三个实现中，分离都遵循相同的模式：
| 设备 | 配套应用可接收的内容 | 设备上保持受保护的内容 |
|---|
| Ledger | UFVK / Orchard FVK、地址和公开信息 | 支出权限 / 私有密钥材料 |
| Keystone | UFVK + Unified Address | 种子 / 支出密钥 |
| Hito | UFVK、Unified Address、种子指纹和网络信息 | 种子和私有支出密钥 |
作为硬件签名环境的 Ledger
Ledger 是一家硬件钱包公司。其设备围绕 Secure Element 构建，这是一种专用于存放私有密钥材料并使其与设备其余部分及任何连接物在物理上隔离的芯片。Secure Element 正是 Ledger 设备值得作为冷存储信赖的全部原因。这意味着，即使连接到它的电脑或手机遭到入侵，Secure Element 内的密钥也无法被提取。
不过，Ledger 设备本身对于任何特定加密货币都是空白的。它需要在设备上安装一个了解如何处理该货币特定密码学的应用程序。
Ledger 设备对于任何特定加密货币都是空白的，因此它需要一个了解该货币密码学的应用程序。对于 Zcash，已有两代应用：
- 最初由 Zondax 构建的“Zcash Shielded”应用，搭配 Zkool 等配套钱包使用，并将于 2026 年 11 月 5 日停止使用，以及
- Ledger 更新的 Zcash 应用（3.9.4+），由 Ledger Wallet Desktop 4.21+ 原生用于 Ironwood 屏蔽 ZEC。
下述密钥隔离模型适用于两者。
Zkool 是手机或电脑上的配套钱包，它与该应用通信。它构建交易并将其发送到 Ledger，设备上的 Zondax 应用随后对其签名并返回签名。
因此，Zondax 是运行在硬件上的软件，Zkool 是运行在硬件外部、使用 Zondax 的应用与设备通信的软件。
什么会离开 Ledger？
Ledger 的 Zcash 软件包含一个用于导出钱包 viewing key 的特定函数，该密钥让软件能够查看余额和交易，而无法支出任何资金。
该函数可以返回以下两种内容之一：
- Unified Full Viewing Key（UFVK），即一次覆盖 Zcash 所有屏蔽池的完整 viewing key，或
- Orchard Full Viewing Key（FVK）
无论哪一种，导出的始终只是 viewing key。无论请求哪个版本，这个函数都无法返回唯一真正能让人转移资金的信息，即支出密钥。
这正是其构建方式的全部要点：它被设计成唯一能够导出的内容，就是可以安全交给配套应用的内容。
Zcash 的密钥层级结构使得每个屏蔽池的支出密钥派生出两种独立内容：
FVK 可以进一步派生出它自己的其他查看相关能力，但该派生路径绝不会回到支出权限。一旦密钥分支进入层级结构的查看侧，它就会停留在那里，无法用于重建其来源的支出权限密钥。
Ironwood 遵循相同的模式，因为它复用了 Orchard 的底层密钥和票据构造。不过，它在共识层面是一个独立的池，拥有自己的承诺树和 nullifier 集合。这意味着 UFVK 实际上是每个池 viewing key 的捆绑包（透明、Sapling、Orchard，以及现在的 Ironwood），而不是一个单一的扁平密钥。
在 Ironwood 激活前导出的 UFVK 不会包含 Ironwood viewing key，因为该池当时尚不存在。这正是钱包在 NU6.3 升级后需要更新，以识别并派生支持 Ironwood 的 UFVK 的原因。
什么留在 Ledger 上？
支出权限保留在设备上。
Ledger 签名器从主机接收交易/PCZT，并根据交易从哪个池进行支出来生成支出授权签名（Ironwood 池，因为 Ledger 当前的集成仅支持 Ironwood）。签名随后在设备上生成，主机只接收签名，而不是私有支出密钥。
这也符合 Ledger 的总体安全模型。其 Secure Element 会隔离私有密钥材料，而 Ledger 的应用安全要求明确禁止应用程序向主机暴露这些秘密。
Ledger 的签名器可以导出 FVK/UFVK，同时独立执行交易签名。这两项能力通过独立函数提供，而非捆绑在一个函数中。
这在实践中意味着什么？
假设你的 Ledger 中有 10 个 ZEC。
配套钱包可以拥有 UFVK，因此能够确定：“这个钱包已收到 10 个 ZEC。”它可以扫描并显示交易与余额。
但如果有人入侵了配套钱包，仅有 UFVK 并不能让他们创建支出授权签名。
独立支出授权签名的目的，是使硬件钱包等受限设备能够授权屏蔽支出，而无需自行执行完整的 zk-SNARK 证明。
Zondax Ledger 应用；硬件钱包一侧
什么是 Zondax？
Zondax 是一家第三方开发公司，构建了 Ledger Zcash 应用。它是运行在 Ledger 硬件上的实际固件应用程序，首先赋予设备理解和处理 Zcash 交易的能力。
Zondax 是外部开发者。Ledger 硬件本身并不具备处理 Zcash 交易的能力，该能力完全来自 Zondax 的软件。
原始 Zcash Ledger 实现
Zondax 的 Ledger Zcash 应用仓库是运行于 Ledger 设备上的软件。该应用最初专注于 Sapling 屏蔽交易，而当时 Orchard 尚未作为 Zcash 的主要屏蔽池存在，因此，Sapling 支持就是 Ledger 设备使用屏蔽 ZEC 所能做到的全部范围。
其架构说明了这种分离：主机/配套端准备交易信息，而 Ledger 处理敏感密钥操作和签名。
即使在最早版本的 Zcash 硬件钱包支持中，核心原则——在主机构建和生成证明，然后在设备上隔离签名——已是既定设计。
向 Orchard 的演进
Ledger 的工作转向了 Orchard + PCZT。这是一项具有重大意义的过渡，而不是小幅更新，因为 Orchard 使用不同的证明系统（Halo 2，相对于 Sapling 的 Groth16）以及不同的票据和密钥构造，所以扩展仅支持 Sapling 的固件以处理 Orchard 签名，需要在设备端建立新的密码学基础，而不只是固件补丁。
然而，随着 Zcash 转向 Ironwood，Zondax 和 Ledger 将开发重点转向直接支持 Ironwood，而不是先完成 Orchard 实现，再为 Ironwood 重新设计。这代表了 Ledger 实现演进的又一个阶段，因为 Ironwood 建立在 Orchard 密码学架构之上，同时引入独立的屏蔽池和额外协议变更。
该 Ledger 应用内部发生什么
最终流程描述如下：
- 主机构建一个 PCZT。
- 主机将相关交易信息发送给 Ledger 设备。
- 设备生成 Orchard 支出授权签名。
- 主机处理其后的一切内容，包括绑定签名和最终交易组装。
运行在 Ledger 内部的应用绝不会看到或生成支出授权签名本身以外的任何内容，而所有计算量大或数据需求高的工作（证明、绑定、组装）均留在主机上，主机无需因这些工作而被授予密钥材料的信任。
Ledger 的原生屏蔽集成；Ledger Wallet Desktop
Ledger 最新的 Zcash 集成，提供了一个具体示例，展示如何在配套软件与硬件钱包之间分离屏蔽交易构建和安全关键签名。
通过 Ledger Wallet Desktop 4.21+ 和 Zcash 设备应用 3.9.4+，用户可以直接通过 Ironwood Wallet Desktop 发送和接收 ZEC 屏蔽 Ledger。该集成支持私密到私密转账、从透明池屏蔽、解除屏蔽至透明池、私密收款地址和备注。交易会在 Ledger 设备上验证和签名，而不是仅依赖电脑显示的信息。
该架构的关键部分是查看能力与支出能力的分离。在私密余额同步期间，Ledger 会导出 Unified Full Viewing Key（UFVK），并将其本地存储在电脑上。UFVK 允许 Ledger Wallet Desktop 检测相关屏蔽交易并确定钱包余额，但不赋予其支出资金的权限。安全关键的支出权限仍留在 Ledger 设备上，由该设备执行最终签名操作。这在管理钱包状态和构建交易的电脑与保护授权支出能力的硬件设备之间建立了明确边界。
然而，当前集成仅限于 Ironwood。它不会通过 Ledger Wallet Desktop 显示或管理 Orchard 或 Sapling 资金。从历史上看，这一点很重要，因为 Ledger 早期的 Zcash 开发与 Orchard 屏蔽支持相关，之后实现才演进至 Ironwood 协议。
这种过渡还凸显了密钥和账户兼容性的重要性。Ledger 有一个由 Zondax 开发的较旧“Zcash Shielded”应用，并由 YWallet 和 zkool 等集成使用，目前正被淘汰。由于该旧应用对屏蔽账户使用了不同的派生方案，其 Sapling 账户无法简单地通过新的 Ledger 应用重现。
因此，该集成既说明了屏蔽硬件钱包支持的进展，也说明了剩余限制。Ledger 现在可以提供完整的 Ironwood 体验，其中配套软件负责钱包同步和交易准备，硬件设备则仍是支出的安全边界。
同时，历史账户兼容性、仅支持特定屏蔽池、硬件交易大小限制、平台限制，以及解析和验证屏蔽交易所涉及的计算和固件限制，表明对 Zcash 的硬件钱包支持不仅取决于协议能力，也取决于各个具体实现的设计和资源。
Zkool + Ledger — 使用官方 Zondax 应用
作为 Ywallet 的继任者，Zkool 继承了屏蔽冷签名的目标，但采取了不同路径来实现它；这一路径直接受到如下事实影响：如果签名应用无法安全分发，仅有密码学并不能使集成变得可用。
https://youtu.be/eagkCIv3BlQ?si=7w5YfLlRER77bASw
Zkool 对 Zondax 应用的使用
Zkool 转向使用由 Zondax 开发的官方 Ledger Zcash 应用，而不是 Ywallet 已放弃的专有 Ledger 应用。Zkool 没有维护一个 Ledger 商店不接受的自定义应用，而是基于已经被接受并通过 Ledger 自身生态系统分发的应用进行构建。
这种转变意味着用户不再需要依赖安装未签名的自定义 Ledger 应用来使用此集成，因为 Zondax 的应用通过 Ledger 的生态系统正式分发。
不过，这一集成将在 2026 年 11 月 5 日面临重要变化，届时 Ledger 将逐步淘汰旧版 Zcash Shielded 应用，其支持计划结束。由于 Zkool 的 Ledger 集成依赖该应用，这一变化引发了关于现有连接未来可用性的疑问。对 Zkool 的确切影响取决于它能否在 Ledger Wallet 之外继续使用旧版应用，或迁移至兼容替代方案。
支持的屏蔽池
根据 Ywallet 开发者的说法，Zkool 的 Ledger 集成使用了由 Zondax 开发的官方 Ledger 应用，并支持透明和屏蔽 Zcash。不过，其屏蔽支持仅限于 Sapling，不支持 Orchard，此外还有其他集成限制，例如每种类型最多五个输入和输出，以及不兼容 Ledger Live。
这一限制反映了当时底层 Zondax Ledger 实现的范围。Zondax 早期的 Ledger 工作提供了对 Sapling 的支持，而其随后于 2024 年发布的 Zcash Shielded Ledger 应用最初不包括 Orchard 和 Unified Addresses。因此，围绕该应用构建的集成继承了其所依赖硬件钱包实现的功能与限制。
随着专用 Zcash Shielded Ledger App 于 2024 年 11 月发布，情况随后发生了变化。Zondax 表示，该应用已通过 Ledger Live 正式发布，之后又发布了集成指南以及 Rust 和 JavaScript 软件包，使其他钱包能够与其集成。然而，在发布之初，该应用仅与 Zecwallet Lite Desktop 通信，而更广泛的钱包集成仍在开发中。
下一阶段是开发 Ledger 更新的、基于 Rust 的 Zcash 应用。截至 2026 年 6 月，Ledger 报告称 UFVK 共享和 Orchard Unified Address 生成已经实现，而 Orchard 交易签名和 ClearSign 仍在开发中。Ledger 还表示，随着协议变更，这项工作将延续至 Ironwood 路径。
Ironwood 随后要求整个 Zcash 钱包生态系统进行更新。Zkool 自 6.24.0 版本起发布了对从 Orchard 迁移至 Ironwood 的支持，并在后续版本中持续完善迁移和交易流程。另一方面，Ledger 于 7 月 27 日将 PCZT v2 签名合并至其新应用，尽管截至 8 月 20 日，该实现尚未完成 Ledger 的审核及 Ledger Live 的上线；此后这一里程碑已实现，Ledger Wallet Desktop 4.21+ 现已直接提供原生 Ironwood 支持。
https://forum.zcashcommunity.com/t/a-path-forward-for-ledger-and-zcash/50951/177
因此，最好不要将这一演进理解为一次单一的 Zondax 到 Ironwood 升级，而应理解为多项相关的发展：最初聚焦于 Sapling 的 Zondax 实现、2024 年的 Zcash Shielded Ledger App、具备 Orchard 和 PCZT 支持的更新版 Ledger Rust 应用、Ledger 在 Ledger Wallet Desktop 中的原生集成，以及随着生态系统过渡至 Ironwood，Zkool 等钱包所进行的并行更新。
当前 Ledger 设备和平台对 Zcash 的支持
Zcash 在 Ledger 上的支持取决于
- 设备型号
- 已安装的应用
- 用于管理它的平台，以及
- 交易是透明的还是屏蔽的。
截至 2026 年 7 月 21 日（Ledger 的最后更新），Zcash Shielded 应用支持 Nano S Plus、Stax 和 Flex，但尚不支持 Nano X 或 Nano Gen5。
Nano X 以及除原始 Nano S 外的其他型号仍可使用经典 Zcash 应用，该应用支持透明交易以及将屏蔽资金花费至透明地址（解除屏蔽），但不支持屏蔽至屏蔽交易的签名。原始 Nano S 两种应用都不支持，因为 Ledger 正在逐步停止对该设备的支持，且最新的 Zcash 应用无法在其上使用。设备可连接至 Ledger Wallet（原 Ledger Live），即 Ledger 的配套应用；该应用在桌面端支持 Windows、macOS 和 Linux，在移动端支持 iOS 和 Android。
Ledger 已在基于 Ironwood 池构建的 Ledger Wallet Desktop 中加入原生屏蔽 Zcash，从而不再需要单独的配套钱包。Ledger 的 iOS 和 Android 移动应用尚不支持屏蔽 ZEC，尽管未来版本计划提供移动端支持。
在 Ledger 自有软件之外，屏蔽使用取决于兼容的配套钱包及其支持的平台。随着 Ledger 持续扩展 Ironwood 支持，兼容性取决于设备型号、固件、应用版本和操作系统，因此一般的 Zcash 支持并不必然保证兼容性。
https://www.youtube.com/watch?v=VhkhfG0LCFs
YWallet 冷签名；一种较早的方法
Ywallet 是一个独立于 Ledger 和 Zondax 的配套钱包，它探索了自己的屏蔽冷签名路径。
Ywallet 在历史上很重要，因为它探索了针对 Zcash 的冷签名，这意味着签名设备可以与在线钱包分离。
为在 Ledger 硬件上实现这一架构，Ywallet 构建了自己的 Ledger 应用——一个专有应用，与上一节介绍的 Zondax 应用不同。这意味着 Ywallet 并不依赖 Zondax 现有的 Sapling 实现；它拥有运行于签名端的自有固件。
为何该集成很重要
拥有密码学和签名代码还不够。硬件钱包集成不纯粹是密码学问题，也不可避免地涉及分发和平台问题。至少包括：
- 应用审批／分发——硬件制造商的官方应用商店是否会接受并分发该应用
- 固件／应用安全——该应用是否满足制造商对处理密钥材料的安全要求
- 通信协议——配套钱包与设备实际如何交换交易数据
- 与钱包的兼容性——签名应用的数据格式和流程是否符合配套钱包的预期
- 支持的屏蔽池——该应用实际上能够为 Sapling、Orchard（以及现在的 Ironwood）中的哪些进行签名
Ywallet 的专有 Ledger 应用满足了密码学和架构要求；它可以为屏蔽 Zcash 交易签名，但未获 Ledger 的官方应用商店接纳。
逐步弃用专有 Ledger 应用
由于该应用未被官方接纳，Ywallet 必须要求用户安装未签名的固件才能使用它；这会对用户造成真实的安全妥协，而 Ywallet 选择不向用户提出这一要求。因此，Ywallet 最终放弃了该特定集成，而非走上这条路。
后续开发并未复兴专有应用，而是通过 Zkool（Ywallet 的继任者）转向官方由 Zondax 构建的 Ledger 应用，以已获 Ledger 分发生态系统接纳的标准化实现，取代了自定义且被拒绝的实现。这一转变最终使可行的 Ledger 集成再次成为可能。
Ywallet 的遗产
即使 Ywallet 本身退出了积极开发，其创建者 Hanh——同时也是 ZCG 成员——仍然是生态系统中具有影响力的声音，尤其是在 Ironwood 的迁移引发有关资金似乎消失的问题报告时。
ZODL：一名真实用户在 Orchard → Ironwood 迁移后遭遇资金缺失
一名用户 Jmo0615 报告称，在从 Orchard 迁移至 Ironwood 后，其先前在 ZODL 钱包中可见的资金不再显示。他们表示已恢复原始助记词，重置并恢复钱包，并允许 ZODL 版本 3.14.1 (1) 完全同步。他们还确认没有涉及 Keystone 硬件钱包。
尚未证实这些资金确实丢失。更确切地说，这被怀疑是与钱包发现或迁移相关的问题：在过渡至 Ironwood 后，先前可见的资金不再显示。未被检测到或显示的资金不应自动被描述为永久丢失的资金；在理解迁移问题时，这一区别非常重要。
https://forum.zcashcommunity.com/t/funds-not-showing-since-ironwood/57792
Zkool：“锁定的票据”可以解释看似不可用的资金
屏蔽钱包的另一个重要方面是，钱包状态会如何影响用户实际可以花费的资金。Hanh 解释说，用户可能会通过币种控制意外锁定一张票据；该功能允许用户手动选择用于支出的票据。在这种情况下，票据可能仍存在于钱包中，但被标记为不可用于支出。
这凸显了调查钱包问题时的重要区别。钱包中存在的 ZEC 数量并不总是等于当前可支出的数量。票据选择、同步、迁移状态、钱包恢复和币种控制设置等因素都会影响显示余额或可支出余额。因此，关于“资金缺失”的报告应仔细区分：未被检测到或显示的资金、已被检测到但不可支出的资金，以及实际丢失的资金。
https://youtube.com/shorts/eAOMRVYJFTA?si=xytBs-wZKn8hmu8D
2. Keystone
什么是 Keystone？
Keystone 是一款气隙硬件钱包。在签名过程本身，其签名设备与配套应用之间没有直接的有线或无线连接，而是通过二维码通信。此处它与 Zashi（现已更名为 Zodl）配对，后者是 Zcash 的原生配套钱包；这种配对使密钥隔离原则格外明确且易于追溯。
Keystone／Zashi 流程
Keystone 与 Zashi 的 Zcash 集成使这种分离尤为明确。当你将 Keystone 连接至 Zashi 时，Unified Full Viewing Key 会从 Keystone 传输至 Zashi。
因此，流程如下：
Zashi 可以使用 UFVK 做什么？
Zashi 可以用它来：
- 识别传入的屏蔽交易
- 确定余额
- 获取有关屏蔽活动的信息
但它不能仅因为拥有 UFVK 就花费这些资金。
UFVK 是一种“查看能力”，允许获知余额和交易，但不允许支出。
什么保留在 Keystone 内部？
助记词／支出授权保留在 Keystone 上。Zashi 不会接收助记词、支出密钥或支出授权私钥。它接收 UFVK、地址信息以及只读操作所需的信息。
这两部分共同构成了完整图景。离开设备的内容，如 UFVK、地址和只读信息，足以让 Zashi 监控账户，但任何离开设备的内容都不足以将资金从中转出。
这就是为什么 Zashi 和 Keystone 的集成可以提供屏蔽冷存储。钱包应用可以监控账户，而无需拥有从中支出所需的授权。该集成专门推出，以实现屏蔽 ZEC 的冷存储。
当你想要支出时：
3. Hito
Hito 遵循与 Keystone 非常相似的密钥隔离模型，但其实现更新。Hito 并非与 Zashi 这样的现有配套钱包配对，而是附带自己的 Android 钱包；硬件设备与该 Android 应用之间的引导流程记录在 Hito 的开发里程碑中。
引导：Hito 应用接收什么
Android 钱包在引导硬件账户时使用：
- Unified Full Viewing Key（UFVK）
- Unified Address
- ZIP-32 助记词指纹
- 网络信息
请注意，Android 应用绝不会接收硬件钱包的助记词或私有支出密钥。
Hito 应用获得什么？
记录在案的引导信息包括：
- UFVK
- Unified Address
- ZIP-32 助记词指纹
- 网络
UFVK 为 Android 钱包提供了以具备查看能力的钱包身份操作账户所需的信息，而无需接收助记词。助记词指纹是从助记词派生的固定长度标识符，用于识别不同账户；它并非助记词本身，也不赋予任何支出能力，因此其存在并不与上述“绝不会接收助记词”的说法矛盾。
什么保留在 Hito 上？
实际的助记词、私有支出密钥和签名授权仍保留在硬件设备上。Hito 随后离线执行签名。
当前 Hito 里程碑指出，完整的创建、导出、离线签名和导入工作流程已经可用，并具备 BLE 传输和经由 BBQr 二维码导出已签名 PCZT 的功能。
值得明确指出这一工作流程，因为它是本报告前文所述完整周期的具体实例：Android 钱包创建未签名的 PCZT，将其导出至 Hito，Hito 使用其隔离的密钥材料离线签名，然后将已签名的 PCZT 导入回 Android 钱包。
在任何时刻，助记词或支出密钥都不会向任一方向跨越这一边界。
Orchard 到 Ironwood：硬件钱包支持的演进
Orchard 是 Zcash 协议中的一个屏蔽资金池，使用户能够以更强的隐私性存储和交易 ZEC。Orchard 在网络升级 5（NU5）中引入，使用 Halo 2 证明系统和重新设计的密码学架构，以支持不泄露发送方、接收方或金额等敏感交易信息的屏蔽交易。
Ironwood 是在 Zcash 的 NU6.3 网络升级中引入的屏蔽资金池，作为 Orchard 资金池的继任者。它采用 Orchard 密码学协议，同时引入了旨在提升屏蔽资金长期安全性的变更，包括量子可恢复性和对供应完整性的更强保障。
首先必须澄清，Ironwood 并未用一套完全全新的密码学系统替代 Orchard 协议。Ironwood 是一个基于现有 Orchard 协议构建的新屏蔽资金池。这意味着它们具有相同的 Action 结构、相同的 Halo 2 证明系统，以及相同的票据和密钥构造。
Ironwood 拥有自己的票据承诺树、无效器集合、锚点和价值池，因此在共识层面上它确实是一个独立的资金池。但在密码学上，它是 Orchard 的扩展，而非重建。
这样设计是为了：
- 供应完整性。 2026 年 5 月 29 日，安全研究员 Taylor Hornby 私下披露了 Orchard 零知识证明系统中的一个严重可靠性漏洞，该漏洞本可能允许创建伪造的 ZEC，且不会留下链上痕迹。由于 Orchard 的交易数据是私密的，没有人能够独立验证修复前是否未曾创建任何伪造的 ZEC。封存旧资金池并从零开始建立新资金池，以原地修补 Orchard 无法做到的方式解决了该问题。
- 确保量子可恢复性。 Ironwood 的设计使其资金能够在底层离散对数假设一旦被攻破时参与未来的恢复机制。
- 尽量减少实现变更。 没有设计一套完全全新的屏蔽协议，而是复用了 Orchard 已被验证的架构。这意味着需要从头编写的新交易、证明、钱包和硬件钱包代码大幅减少。
公开时间线
- 5 月 29 日：Orchard 漏洞被披露。
- 6 月：Orchard 交易受到临时限制，同时初步修复通过 NU6.2 发布。6 月 12 日，一名核心开发者将完整升级目标定为 7 月 21 日；之后延后一周。社区有人担忧 Keystone 持有者会是最后一批迁移者，随后一名核心开发者回应称，Keystone 将从第一天起支持 Ironwood，固件目标发布时间为 7 月 3 日，等待 Zcash 核心最终确定签名常量和 Orchard API 变更。
- 7 月初：NU6.3 进入测试网；Zebra 6.0.0 于 7 月 10 日发布。
- 7 月 27–28 日：Ledger 的 Ironwood PCZT v2 签名工作合并到集成分支。Ironwood（NU6.3）于 7 月 28 日在区块 3,428,143 激活，通过一个旋转门封存原始 Orchard 资金池，该机制将可从 Orchard 流出的 ZEC 数量限制为曾合法存入其中的数额，并引入新的交易格式。
Zebra 成为必需的节点，因为 zcashd 不支持新的共识规则。地址不会改变，因为 Ironwood 复用了 Orchard 的接收方结构，因此钱包会自动将现有地址路由至新资金池。钱包确实需要迁移功能，因为 Orchard 资金最终必须由其所有者转移到 Ironwood，而接收 Orchard 的新输出如今已完全被共识阻止。
技术上有哪些变化
交易格式从版本 5 变为版本 6，因此单笔交易可在现有 Sapling/Orchard/透明组件之外携带一个 Ironwood 组件。PCZT 也随之扩展：
- 编码从 PCZT v1 升级到 v2。
- 一个独立的 Ironwood bundle 现在与 Sapling 和 Orchard bundle 并列存在。
- 支持 v6 交易和新的 v6 sighash。
- 票据明文新增一个版本（V3）。
sighash 的变更对硬件钱包尤其重要。在 v6 中，Orchard 和 Ironwood 锚点被排除在签名哈希之外，仅纳入授权数据摘要。这是实实在在的固件变更，而不只是版本号升级。设备必须正确实现新的 sighash 并自行重新计算，而不能相信配套应用声称其正在批准的内容。
隔离契约本身没有改变：设备仍然只返回花费授权签名，绝不返回 alpha，也绝不生成绑定签名；主机仍然负责证明及其他所有工作。
不过，v6 改变了一条签名者规则：虚拟填充花费由 IO Finalizer 而非设备签名，因为设备无法根据真实票据数据验证它们。设备的 Signer 角色会跳过它们，而不会被要求签署无法检查的内容。显示的费用现在也会将 Orchard 和 Ironwood 的价值余额相加，因为一笔 v6 交易可在同一笔交易中从任一资金池花费。
在实践中，正确处理资金池账务至关重要，而不只是理论问题。Brave 自己的 Zcash 钱包近期出现的一个漏洞是很好的例子：其费用计算假定所有屏蔽输入都属于旧版 Orchard 资金池，导致交易实际涉及 Ironwood 时出现重复的 Action 和错误的费用估算。这正是硬件钱包签名背后的“自行重新计算，不要信任主机”原则旨在发现的错误类别。配套钱包错误处理了资金池账务，只有独立检查自身计算的设备才能在为其签字前标记出这个问题。
各签名方案的现状
Ledger 刚刚彻底改变了局面。 2026 年 9 月 23 日，Ledger 在 Ledger Wallet Desktop 内直接推出了原生屏蔽 Zcash 支持，不再需要单独的配套应用。你的花费密钥留在设备上，计算机完成交易计算，而你在签名前于屏幕上批准一切。它仅支持 Ironwood，不支持旧的 Orchard 或 Sapling 资金池。缺点是，由 Zondax 构建、需要配套钱包如 Zkool 才能工作的旧版“Zcash Shielded”应用正在停用。Ledger 将于 11 月 5 日下架该旧应用，因此仍在使用它的用户需要在此之前转移资金。
Keystone 状况良好。 固件 3.0.2 在 7 月新增了完整的 Ironwood 支持，并且这仍是当前稳定版本所需的支持。不过，必须使用该版本或更新版本才能签署任何内容。
Hito 已超过最初的测试网里程碑。 它已在实体硬件上成功签署并提交了第一笔真实的 Orchard 到 Ironwood 交易（最初在测试网上）。后续更新确认了生产硬件上的主网流程（Ironwood→Ironwood、Ironwood→透明交易，以及其他流程）。稳定固件和更广泛的发布仍在进行中。
Zondax 和 Zkool 目前仍处于变动之中。Zondax 的应用正从 Ledger 上退役。Zkool 依赖该应用与 Ledger 设备通信，但尚未说明旧应用消失后该角色将如何处理。目前尚不清楚它今后是否仍与 Ledger 用户相关，还是其未来主要面向其他设备。
迁移本身是最大的连锁影响。由于跨资金池的金额是公开的，钱包会随着时间推移将转账分散为标准面额，而不会将余额作为一个可见的大额整体转移；这意味着每次迁移需要签署许多交易，也正是批量 PCZT 签名对硬件钱包如此重要的原因。
Ledger 的固件工作也遇到了硬件限制：一次真实票据花费在单条命令中可能达到数万次密码学系统调用，从而触发设备看门狗。修复方案将有限域运算移至软件中，并需要共享暂存状态，以满足 Nano X 的堆栈限制。
https://forum.zcashcommunity.com/t/ironwood-is-here-updated-wallets-libraries-aug-20/56557/40
一图看懂演进
