シールド付きコールド署名
重要な考え方： コンパニオンウォレットは、シールド付きトランザクションを構築・監視するために必要なすべてを把握します。ハードウェアウォレットだけが支出を承認する権限を保持します。この分離こそが、シールド付きコールド署名の要点です。
Zcashでのシールディングでは、資金を公開された透明アドレスからプライベートなシールド付きアドレスへ移動し、Zcashのプライバシー機能によってトランザクション詳細を隠します。
ZECをシールディングすると何が変わるか？
透明なZcashトランザクションでは、次の情報は
ブロックチェーン上で観測できます。
ZECをシールディングすると、資金はプライベートプール（Ironwoodなど）へ移ります。ブロックチェーンは、プライベートなトランザクション詳細を明かすことなく、トランザクションの有効性を検証できます。2026年7月28日のNU6.3アップグレード以降、新たにシールディングされた資金はIronwoodプールに入ります。古いOrchardプールは新規入金を受け付けなくなりましたが、引き出しは引き続き可能です。
シールド付きトランザクションの構成要素
1. ノート（シールド付き残高記録）
ノートとは、ユーザーが所有する未使用のZEC額を表す、プライベートな暗号学的記録です。
残高が平文で記載される公開ブロックチェーンとは異なり、シールド付きノートは価値と所有権の詳細を暗号化するため、オンチェーンの観測者は誰が資金を所有しているか確認できません。
トランザクション開始時、コンパニオンウォレットは台帳をスキャンし、ユーザーの未使用ノートを特定して、どのノートを支出するか選択します。
2. ヌリファイア（二重支出検出メカニズム）
ノートの詳細は公開台帳から隠されているため、ネットワークには、どのノートが支出されたかを明かさずに二重支出を検出する仕組みが必要です。
ヌリファイアは、特定のノートから導出される一意の暗号学的マーカーです。ノートが支出されると、そのヌリファイアがブロックチェーンに公開されます。
ネットワークは、そのヌリファイアが以前に記録されていないことを検証します。記録されていなければ、支出を受け入れられます。重要なのは、外部の観測者はヌリファイアから、それがどの特定ノートに由来するかを判定できないことです。
コンパニオンウォレットは、トランザクションデータの組み立ての一部として、適切なヌリファイアを導出・構築します。
鍵
鍵は、資金へのアクセスを制御し、ウォレットが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）は、厳格なセキュリティ分離を維持しながら、完全な読み取り専用の可視性を提供します。受信・送信ノートの暗号文の両方を復号することで（送信閲覧鍵コンポーネント経由）、FVKのみを持つコンパニオンウォレットは、単なる残高推移ではなく、完全でラベル付きのトランザクション履歴を表示できます。
複数のリンク不可能な多様化支払いアドレスは、同一のFVKおよび受信閲覧鍵（IVK）を共有するため、ブロックチェーンスキャンの負荷を増やさずに無制限のアドレス生成が可能です。
この機能的分離がコールド署名ワークフローの基盤となります。継続的なチェーンスキャン、履歴追跡、アドレス管理はすべてホストソフトウェアへ委ねられ、支出権限はハードウェアデバイス上で隔離されたままです。
重要な区別：UFVK と支出鍵
UFVKは共有できます。支出鍵はハードウェアウォレットに残さなければなりません。
コンパニオンウォレットは閲覧鍵を使ってウォレットを監視し、入金を検出し、ノートを特定し、トランザクション準備を補助します。支出承認に必要な秘密鍵は保有しません。
前述のとおり、鍵の分離はコールド署名アーキテクチャの基盤です。
コンパニオンウォレットは、資金を制御することなく、トランザクション準備に必要な作業の大半を実行できます。ハードウェアウォレットは、準備済みトランザクションを受け取り、最終署名操作を行うだけです。
ハードウェアウォレットメーカーがこの分離を自ら発明する必要はありません。Zcashの鍵設計は、すでにプロトコルレベルで閲覧機能と支出権限を分離しています。メーカーはその既存構造の上に署名・エクスポート機能を構築するだけです。プロトコルでは、シールド付きアドレスや完全閲覧鍵などの情報を支出鍵から導出できますが、支出鍵自体は秘密のままです。そのため、Ledger、Keystone、Hitoなどのハードウェアウォレットは、資金を支出できる秘密鍵を公開せずに、コンパニオンソフトウェアへ必要な閲覧情報を渡せます。
コンパニオンウォレットが鍵情報で実際に行うこと
閲覧鍵マテリアルを使い、コンパニオンウォレットは次を実行できます。
- 資金とノートの特定
- 支出可能なノートの判定
- 関連アドレスの導出または特定
- トランザクションの構築
- 必要な証明の生成または調整
- 署名用トランザクションの準備
トランザクションを構築する必要があることは、秘密の支出鍵が必要であることと同じではありません。この分離は、ハードウェアウォレット統合の中核的なセキュリティ概念の一つです。
シールド付きトランザクションの構築と承認
これらはトランザクションの作成・承認に関わるプロセスです。簡潔に言えば、資金送付のためにウォレットがそのデータで実際に行う処理です。
トランザクション構築（シールド付きトランザクションの組み立て）
トランザクション構築とは、ユーザーが意図した支払いから、有効なZcashトランザクションを作成するために必要な情報を組み立てるプロセスです。
トランザクション構築プロセスは、選択済みノート、受取人、金額、手数料、ヌリファイア、その他の必要なトランザクションデータをトランザクション構造に統合します。シールド付きトランザクションでは、必要なゼロ知識証明と署名の生成に必要な情報も準備します。
通常、この段階はコンパニオンウォレットが実行します。コンパニオンウォレットは
- 支出するノートを選択する
- トランザクションの入力と出力を決定する
- 必要な値を計算する
- 後で証明・署名されるトランザクションデータを準備する
コールド署名環境では、生成されたトランザクションデータをPCZTにパッケージ化し、セキュリティ上重要な署名ステップのためにハードウェアウォレットへ渡せます。
証明（プロトコル有効性の実証）
証明とは、トランザクションがZcashプロトコル規則に従うことを示す、ゼロ知識証明（Halo 2またはGroth16など）の生成を指します。
この証明により、ネットワークは次を保証できます。
- 支出ユーザーがノートを支出する権限を持つこと
- ノートが実際に存在すること
- 対応するヌリファイアが一意であること
- 入力合計が出力合計と手数料の合計に等しいこと
これらすべてを、基礎となる私的詳細を明かさずに実現します。
証明生成は計算負荷が高い処理です。この責任をコンパニオンデバイスへ移すことで、ハードウェアウォレットが停止したりメモリ不足になったりするのを防ぎます。
署名（支出の承認）
署名は証明とは本質的に異なります。デジタル署名は、秘密鍵保有者が作成する明示的な承認印です。
ゼロ知識証明がトランザクションの有効性を検証する一方、デジタル署名は支出権限を証明します。この署名は、真の所有者が特定の送金パラメータを承認したことを証明します。
署名に必要な計算能力は最小限であり、ハードウェアウォレットに適しています。
シールド付きコールド署名とは？
シールド付きコールド署名は、秘密の支出鍵をインターネット接続されたコンパニオンウォレットから隔離したまま、Zcashのシールド付きトランザクションを承認する方法です。トランザクションはオンラインコンピューターで構築・準備でき、オフラインまたは別途隔離されたハードウェアウォレットが、保護された鍵でトランザクションを承認します。
プロセスは次のように簡略化できます。
コンパニオンウォレットは構造化されたトランザクションパラメータをハードウェアデバイスへ送ります。デバイスは、秘密の支出鍵をホストマシンへ決して公開せず、内部でペイロードに署名します。
コンパニオンウォレットとハードウェアウォレット
シールド付きトランザクションでは、コンパニオンウォレットとハードウェアウォレットの両方が関与し、それぞれ異なる機能を担います。
コンパニオンウォレット
コンパニオンウォレットとは何でしょうか？
コンパニオンウォレットはコンピューターまたはモバイルデバイス上で動作し、次のようなトランザクション作成の大部分を実行します。
- 支出するノートの選択
- トランザクションの構築
- 必要なトランザクションデータの計算
- 必要なゼロ知識証明の生成の調整
コンパニオンウォレットが役立つ理由
コンパニオンウォレットはトランザクション作成プロセスを処理しますが、コンピューターがマルウェアに感染すると、攻撃者は次のことを行える可能性があります。
- 実行内容を見る
- 未署名トランザクションを変更する
- 何かを承認するよう欺こうとする
コンパニオンウォレットはハードウェアウォレットに保存された秘密鍵へアクセスする必要がありません。そのため、ハードウェアウォレットが秘密鍵のセキュリティ境界を提供する一方で、トランザクション構築その他の計算処理を担えます。
ハードウェアウォレット
ハードウェアウォレットは、接続された電話やコンピューターから秘密鍵を隔離するオフラインの物理デバイスであり、暗号資産のための安全な金庫として機能します。
ハードウェアウォレットが役立つ理由
コンピューターがマルウェアに感染すると、攻撃者は次のことを行える可能性があります。
- 実行内容を見る
- 未署名トランザクションを変更する
- 何かを承認するよう欺こうとする
秘密鍵はハードウェアウォレットから単純に抽出できないため、デバイスはセキュリティ境界として機能できます。
コンパニオンとハードウェアの機能比較画像
この二つのウォレットの分離は、シールド付きトランザクションでは特に重要です。透明なトランザクションより複雑で、シールド付きノート、ヌリファイア、コミットメント、ゼロ知識証明、トランザクション署名などを含むためです。
ハードウェアウォレットがすべての計算処理を行うのは現実的ではありません。代わりに、コンパニオンウォレットがトランザクションを準備し、署名に必要な情報をハードウェアウォレットへ提供します。一方、秘密の支出鍵はハードウェアデバイス内で隔離されたままです。
鍵の隔離
鍵の隔離とは、支出を承認できる秘密鍵がハードウェアウォレットから決して出ないことを意味します。コンパニオンはトランザクションを準備できますが、署名はできません。
鍵の隔離とは、トランザクション承認に必要な秘密鍵を、コンパニオンウォレットおよびそれが動作するデバイスから分離して保持することです。シールド付きコールド署名環境では、コンパニオンウォレットはトランザクションを構築し必要な証明を調整できますが、ハードウェアウォレットは機密性の高い秘密支出鍵を隔離したまま保持します。
コンパニオンのコンピューターまたは電話が侵害された場合、攻撃者は署名前のトランザクションとやり取りできる可能性がありますが、理想的にはハードウェアウォレットから秘密鍵を抽出できません。したがって鍵はハードウェアデバイスのセキュリティ境界内に留まります。
この分離により、コンパニオンウォレットはトランザクション構築と計算タスクを実行できますが、トランザクション承認に必要な鍵マテリアルへ直接アクセスすることはありません。
重要な区別は、「閲覧鍵」はアプリがシードの弱い版を受け取ることを意味しない点です。
Zcashでは、Full Viewing Key（FVK/UFVK）は支出鍵から意図的に導出され、保有者に関連するシールド付き活動の検出・復号能力を与えますが、支出承認はできません。FVKは支出鍵のより秘密性が低い派生物です。
重要なプライバシー上の注意点：
したがって、アプリはUFVKだけで資金を盗めませんが、ウォレットの私的なシールド付き活動を確認できます。
そのため、コンパニオンアプリケーションは単に「公開情報」を持つと言うより、閲覧権限を持つと表現する方が正確です。
全体を最も簡潔に言えば、コンパニオンウォレットはウォレットで何が起きているかを知るには十分な鍵マテリアルを得ますが、ウォレット資金に何を行うかを承認するには不十分な鍵マテリアルしか得ません。一方ハードウェアウォレットは支出権限を隔離し、ユーザーがトランザクションを承認したときだけ使用します。
これが、これらのシールド付きZcashハードウェアウォレット設計の中核となる鍵隔離モデルであり、まもなく扱うLedger、Keystone、Hitoにも、実装ごとに同じモデルが現れます。
PCZT
PCZTはPartially Created Zcash Transactionの略です。Zcashトランザクションと、それをある段階から別の段階へ完成させるために必要な情報を運ぶパッケージです。
これは、まだ構築途中のZcashトランザクションの標準化形式です。異なる参加者またはデバイスがトランザクション作成プロセスの異なる部分を実行し、部分完成トランザクションを相互に渡すことを可能にします。
Zcashのようなゼロ知識暗号資産プロトコルでは、トランザクション構築は単純な公開送金への署名より大幅に複雑です。シールド付きトランザクションには、Halo 2またはGroth16を使用して生成されるような、計算負荷の高いゼロ知識証明が必要です。そのため、ハードウェアウォレットなどの低電力デバイスは、トランザクションワークフロー全体を処理するメモリや処理能力を持たない場合があります。
PCZTの導入は、シールド付き暗号資産アーキテクチャにおける複数の中核課題に対処します。PCZTは、トランザクション作成をモジュール化された独立した役割へ分割する標準化中間データ形式です。強力なコンパニオンコンピューターがトランザクション組み立てと証明生成を担う一方、オフラインのハードウェアウォレットを承認と署名のみに厳格に制限できます。
ハードウェアとコールドストレージの制約
ハードウェアウォレットは秘密支出鍵の保護に安全な環境を提供しますが、通常はコンパニオンコンピューターよりRAM、計算能力、データ転送能力が限られます。これらの制約により、計算負荷の高いゼロ知識証明の生成や、トランザクション構築中に必要な完全なトランザクション状態の維持は非現実的です。
そのため、コンパニオンウォレットが計算負荷の高いタスクを処理し、ハードウェアウォレットは保護された支出鍵でトランザクションを承認する、セキュリティ上重要な操作に集中できます。
これほど制約の多いデバイスが、信頼できるだけの検証をどう実行するのか、疑問に思うかもしれません。
簡潔に言えば、ハードウェアウォレットはコンパニオンコンピューターから任意の値を受け取って署名することはできません。署名対象の値が、ユーザーが承認する意図のトランザクションに対応することを確認する十分な情報が必要です。デバイスは署名プロセスを保護するために十分な解析・検証を実行する必要がありますが、メモリ、計算、ファームウェアサイズ、実装複雑性には厳格な制約があります。
LedgerのOrchard PCZT処理はこの課題の一例です。専用の回路依存解析により制約のあるデバイスでも実装を管理しやすくなる可能性がありますが、対応するトランザクション構造または回路が進化した場合にはファームウェア変更も必要になる可能性を示しています。
この同じ制約への異なる対応を、二つの継続的な取り組みが示しています。
オープンソースのハードウェアウォレットアーキテクチャおよび通常のコンピューターに適した、完全に定数時間の証明パイプラインに関する研究提案がGrant #423で提示されました。その目的は、シールド付きZcashサポートの複雑性と保守負担を減らしつつ、CまたはRustなどの環境で安全に実装できる暗号インフラを調査することでした。
一方の代替的なアプローチは、安価で入手しやすい部品から構築されたオープンソースのエアギャップ署名者、提案された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が分離アーキテクチャを可能にする
Partially Created Zcash Transaction（PCZT）標準は、コンパニオンウォレットとハードウェアウォレットを接続する正式なデータ構造です。
コンパニオンウォレットはノート選択、ヌリファイアの算出、ゼロ知識証明の生成をすべて単独で行えます。これは、ヌリファイア導出に使用する鍵を含め、これらの段階に必要な情報が、支出権限に結びつくものではなく閲覧鍵から得られるためです。その後、コンパニオンウォレットはこれらの要素をPCZTコンテナへパッケージ化します。
PCZTはハードウェアウォレットへ渡されます。ハードウェアウォレットはトランザクションコンテキスト（額や受取人アドレスなど）を読み取り、保護された支出鍵で署名を適用し、更新済みのPCZTをコンパニオンデバイスへ返します。
この設計は厳格なセキュリティ境界を確立します。高性能なホストハードウェアは支出鍵へのアクセスなしに複雑なゼロ知識計算を実行でき、低電力のコールドストレージデバイスは重い暗号計算なしに金融セキュリティを強制できます。
Proverのプライバシー上の妥協
ゼロ知識証明生成をコンパニオンウォレットまたは別のProverへ委任すると支出鍵は隔離されますが、Proverにはノート価値、受取人アドレス、コミットメントなどの機密トランザクション情報へのアクセスが必要です。
PCZTは、承認に必要な秘密支出鍵を転送せずに、この情報を証明用に提供できるようにすることで、アーキテクチャ上の分離を維持します。
これにより、証明権限が支出権限から分離されることが保証されます。Proverは、ユーザー資金を支出する暗号学的権限を得ずに、計算負荷の高い証明生成を実行できます。
PCZTの相互運用性
PCZTがZcashのハードウェアウォレット、マルチシグネチャ、エアギャップ署名ワークフローの重要な部分になるにつれ、独立実装間の相互運用性はますます重要になります。
2026年6月のAngryDaveeによる提案では、PCZTの実装がすでにLedger、Keystone、Hito、OneKey、およびlibrustzcashの参照実装を含むプロジェクト全体に存在していたと指摘されました。しかし提案は、これらの実装がPCZTを一貫して解釈することを確認する共有テストがないことを特定しました。
提案された解決策は、正規のPCZTテストベクターと、完全な作成 → 署名 → 完成ワークフローを対象とするクロス実装テストを含む、オープンソースの相互運用性テストスイートでした。また、トランザクション完成前に異なる署名者からの部分署名情報を結合できる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 | Creator | トランザクションバージョン、コンセンサスブランチID、プールフラグを含むグローバルトランザクションメタデータでPCZTを初期化します。 |
| 2 | Constructor | 透明、Sapling、Orchard、またはIronwoodプールにまたがる、意図された入力と出力でトランザクションを構成します。 |
| 3 | IO Finalizer | 入力・出力の集合が完了したことを宣言し、バインディング署名鍵を計算し、必要に応じてダミー支出に署名します。 |
| 4 | Updater | 完全閲覧鍵、アンカー、Merkle witnessなど、後続参加者に必要なコンテキストデータを添付します。 |
| 5 | Prover and Signer | ゼロ知識証明生成と暗号学的署名を実行します。現代のPCZTバージョンでは、この二つのタスクは完全に独立しており、順次または並列に実行できます。 |
| 6 | Combiner | 異なるデバイスが同じトランザクションの側面を同時に処理する場合、複数のPCZTインスタンスを決定論的に結合します。結合規則には偶発的なデータ損失を防ぐ厳格な競合解決が必要です。 |
| 7 | Spend Finalizer & Extractor | 必要な暗号学的要素をすべて検証し、中間コンテキストメタデータを除去し、ネットワーク送信可能な完成済みZcashトランザクションを生成します。 |
実世界のハードウェアウォレット実装
概要
| デバイス | コンパニオンが受け取るもの | デバイスに残るもの | 転送手段 |
|---|
| Ledger | UFVK / Orchard FVK、アドレス | 支出権限 | USB / BLE |
| Keystone | UFVK + Unified Address | シード / 支出鍵 | QR（エアギャップ） |
| Hito | UFVK、Unified Address、シードフィンガープリント | シードと秘密支出鍵 | QR / ローカル |
複数のハードウェアウォレット実装が開発され、機密性の高い支出鍵をコンパニオンウォレットから隔離しつつ、Zcashのシールド付きトランザクションをどのようにサポートできるかが探究されてきました。Ledger、Keystone、Hitoは、ハードウェアベースの鍵保護をZcashトランザクションワークフローへ統合する異なるアプローチを示します。
シールド付き資金をどう保護するかを理解するには、支出鍵と閲覧鍵を区別することが重要です。三者すべてにおいて、分離は同じ形に従います。
| デバイス | コンパニオンアプリが受け取れるもの | デバイス上で保護されたままのもの |
|---|
| 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ソフトウェアには、ウォレットの閲覧鍵をエクスポートする専用機能があります。この鍵により、ソフトウェアは支出能力を持たずに残高とトランザクションを確認できます。
この機能は次の二つのいずれかを返します。
- Unified Full Viewing Key（UFVK）。Zcashのすべてのシールド付きプールを一度に対象とする完全閲覧鍵、または
- Orchard Full Viewing Key（FVK）
どちらの場合でも、出力されるのは閲覧鍵だけです。どの版を要求しても、この機能には資金移動を実際に可能にする唯一の情報、すなわち支出鍵を返す手段はありません。
これがこの設計の要点です。コンパニオンアプリへ安全に渡せるものだけをエクスポートできるように設計されています。
Zcashの鍵階層は、各シールド付きプールについて、支出鍵が二つの別個のものを導出するよう構築されています。
その後FVKはさらに独自の閲覧関連機能を導出できますが、その導出経路が支出権限へ戻ることはありません。鍵が階層の閲覧側へ分岐すると、そこに留まり、元となった支出権限鍵を再構築することはできません。
Ironwoodは、Orchardの基礎となる鍵とノート構造を再利用するため、この同じパターンに従います。ただしコンセンサスレベルでは独自のコミットメントツリーとヌリファイア集合を持つ別個のプールです。つまりUFVKは単一のフラットな鍵ではなく、プールごとの閲覧鍵（透明、Sapling、Orchard、そして現在はIronwood）の束です。
Ironwoodの有効化前にエクスポートされたUFVKには、そのプールがまだ存在しなかったため、Ironwood閲覧鍵は含まれません。これこそ、NU6.3アップグレード後に、ウォレットがIronwood対応UFVKを認識・導出できるよう更新する必要があった理由です。
Ledgerに残るものは何か？
支出権限はデバイス上に残ります。
Ledger Signerはホストからトランザクション/PCZTを受け取り、トランザクションがどのプールから支出するかに応じて支出承認署名を生成します（Ledgerの現在の統合はIronwoodのみをサポートするため、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実装を完成させてすぐIronwood向けに再設計するよりも、Orchardを直接サポートすることへ開発重点を移しました。これはLedger実装の進化における次の段階であり、IronwoodはOrchardの暗号アーキテクチャを基礎にしつつ、別個のシールド付きプールと追加のプロトコル変更を導入します。
このLedgerアプリ内部で起きること
結果として、フローは次のように説明されます。
- ホストがPCZTを構築する。
- ホストが関連するトランザクション情報をLedgerデバイスへ送る。
- デバイスがOrchardの支出承認署名を生成する。
- ホストがバインディング署名と最終トランザクション組み立てを含む、その後のすべてを処理する。
Ledger内部で実行されるアプリは、支出承認署名そのものを超えるものを見たり生成したりしません。計算負荷が高い、または大量データを必要とする作業（証明、バインディング、組み立て）はすべてホスト側に留まり、ホストを鍵マテリアルについて信頼する必要はありません。
Ledgerのネイティブなシールド付き統合：Ledger Wallet Desktop
Ledgerの最新Zcash統合は、シールド付きトランザクション構築とセキュリティ上重要な署名を、コンパニオンソフトウェアとハードウェアウォレット間でどのように分離できるかの具体例を提供します。
Ledger Wallet Desktop 4.21以降とZcashデバイスアプリ3.9.4以降を使うと、ユーザーはLedger Wallet Desktopで直接、Ironwoodのシールド付きZECを送受信できます。この統合は、プライベート間送金、透明プールからのシールディング、透明プールへのアンシールディング、プライベート受信アドレス、メモをサポートします。トランザクションは、コンピューターで示された情報のみに依存せず、Ledgerデバイス上で検証・署名されます。
このアーキテクチャの重要な部分は、閲覧機能と支出機能の分離です。プライベート残高同期中、LedgerはUnified Full Viewing Key（UFVK）をエクスポートし、コンピューターにローカル保存します。UFVKによりLedger Wallet Desktopは関連するシールド付きトランザクションを検出しウォレット残高を判定できますが、資金を支出する権限は提供しません。セキュリティ上重要な支出権限はLedgerデバイスに残り、最終署名操作を実行します。これにより、ウォレット状態を管理しトランザクションを構築するコンピューターと、支出承認能力を保護するハードウェアデバイスの間に明確な境界が生じます。
ただし現在の統合はIronwood専用です。Ledger Wallet Desktopを通じてOrchardまたはSapling資金を表示・管理することはできません。これは歴史的に重要です。Ledgerの初期Zcash開発は、実装がIronwoodプロトコルへ進化する前のOrchardシールド付きサポートに関係していたためです。
この移行は、鍵とアカウントの互換性の重要性も示します。Ledgerには、Zondaxが開発し、YWalletやzkoolなどの統合で使用された、古い「Zcash Shielded」アプリケーションがありますが、現在廃止されつつあります。この古いアプリケーションはシールド付きアカウントに異なる導出方式を使用していたため、そのSaplingアカウントを新しいLedgerアプリケーションで単純に再現することはできません。
したがって、この統合はシールド付きハードウェアウォレットサポートの進展と残る制限の両方を示します。Ledgerは現在、コンパニオンソフトウェアがウォレット同期とトランザクション準備を処理し、ハードウェアデバイスが支出のセキュリティ境界であり続ける、完全なIronwood体験を提供できます。
同時に、過去のアカウント互換性、特定のシールド付きプールのみへの対応、ハードウェアのトランザクションサイズ制限、プラットフォーム制約、シールド付きトランザクション解析・検証に伴う計算およびファームウェア制約は、Zcash向けハードウェアウォレットサポートがプロトコル機能だけでなく、各個別実装の設計・リソースにも依存することを示します。
Zkool + Ledger — 公式Zondaxアプリの使用
Ywalletの後継として、Zkoolはシールド付きコールド署名という目標を継承しましたが、統合を有用にするには暗号技術だけでは不十分で、署名アプリを安全に配布できなければならないという事実によって直接形作られた、異なる道筋を取りました。
https://youtu.be/eagkCIv3BlQ?si=7w5YfLlRER77bASw
ZkoolによるZondaxアプリケーションの使用
Zkoolは、Ywalletが放棄した独自Ledgerアプリケーションではなく、Zondaxが開発した公式Ledger Zcashアプリを使用する方向へ移行しました。Ledgerのストアが受け入れないカスタムアプリを維持する代わりに、Zkoolは、すでにLedger自身のエコシステムで受け入れられ配布されていたアプリを基盤にしました。
この移行により、ユーザーはこの統合を使うために未署名のカスタムLedgerアプリケーションのインストールへ依存する必要がなくなりました。ZondaxのアプリはLedgerのエコシステムを通じて正式に配布されていたためです。
ただしこの統合は、LedgerがレガシーZcash Shieldedアプリを段階的に廃止し、そのサポートが2026年11月5日に終了予定であるという重要な変更に直面しています。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が除外されていました。したがって、そのアプリケーションを中心に構築された統合は、依存するハードウェアウォレット実装の機能と制限を継承しました。
状況は、2024年11月の専用Zcash Shielded Ledger Appのリリースで変化しました。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 Wallet DesktopにおけるLedger自身のネイティブ統合、そしてエコシステムがIronwoodへ移行する中でのZkoolなどのウォレットにおける並行更新です。
Zcash向け現在のLedgerデバイスおよびプラットフォーム対応
Ledger上でのZcashサポートは、次に依存します。
- デバイスモデル
- インストール済みアプリケーション
- 管理に使用するプラットフォーム
- トランザクションが透明かシールド付きか
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はLedger Wallet Desktopに、Ironwoodプール上に構築されたネイティブのシールド付きZcashを追加し、別個のコンパニオンウォレットを不要にしました。シールド付きZECは、iOSおよびAndroid向けLedgerモバイルアプリではまだサポートされていませんが、将来のリリースでモバイル対応が予定されています。
Ledger自身のソフトウェア以外では、シールド付き利用は互換性のあるコンパニオンウォレットと、その対応プラットフォームに依存します。LedgerがIronwoodサポートを拡大し続ける中、互換性はデバイスモデル、ファームウェア、アプリ版、OSに依存するため、一般的な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自体が活発な開発から退いた後も、その作成者でありZCGメンバーでもあるHanhは、特にIronwoodの移行で消失したように見える資金の報告問題が浮上した際、エコシステムで重要な発言者であり続けました。
ZODL：Orchard → Ironwood移行後、実際の利用者が資金不足を経験した
利用者Jmo0615は、以前はZODLウォレットに表示されていた資金が、OrchardからIronwoodへの移行後に表示されなくなったと報告しました。元のシードを復元し、ウォレットをリセットして復旧し、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はエアギャップ型ハードウェアウォレットです。署名デバイスは、署名プロセスそのものの間はコンパニオンアプリと有線・無線で直接接続せず、代わりにQRコードを通じて通信します。ここでは、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と非常によく似た鍵隔離モデルに従いますが、その実装はより新しいものです。Zashiのような既存コンパニオンウォレットと組み合わせるのではなく、Hitoは独自の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マイルストーンでは、署名済みPCZTのBLE転送およびBBQr QRエクスポートを備え、作成、エクスポート、オフライン署名、インポートのワークフロー全体が稼働していると述べられています。
このワークフローは明示的に名付ける価値があります。これは本レポートで先に扱った完全なサイクルの具体例だからです。Androidウォレットが未署名のPCZTを作成し、Hitoへエクスポートし、Hitoが隔離鍵マテリアルでオフライン署名し、署名済みPCZTがAndroidウォレットへ再インポートされます。
どの時点でも、シードまたは支出鍵がいずれの方向にもこの境界を越えることはありません。
OrchardからIronwoodへ：ハードウェアウォレットサポートの進化
OrchardはZcashプロトコルのシールド付きプールであり、ユーザーがプライバシーを強化してZECを保管・取引できるようにします。Network Upgrade 5（NU5）で導入されたOrchardは、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をサポートすると回答しました。ファームウェアは、最終化された署名定数とZcashコアからのOrchard API変更を条件に、7月3日を目標としていました。
- 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バンドルが、SaplingおよびOrchardバンドルと並んで配置される。
- v6トランザクションと新しいv6 sighashをサポート。
- ノート平文に新バージョン（V3）が追加される。
sighashの変更は、特にハードウェアウォレットにとって重要です。v6では、OrchardとIronwoodのアンカーは署名ハッシュから除外され、承認データダイジェストにのみ供給されます。これは単なるバージョン更新ではなく、実際のファームウェア変更です。デバイスは新しいsighashを正しく実装し、コンパニオンアプリが承認対象だと主張する内容を信用せず、自ら再計算しなければなりません。
隔離契約そのものは変わっていません。デバイスが返すのは依然として支出承認署名だけであり、alphaを返すことはなく、バインディング署名も生成しません。ホストは依然として証明およびその他すべてを処理します。
ただしv6では、署名者規則が一つ変わりました。デバイスには実際のノートデータに照らして検証する方法がないため、ダミーのパディング支出はデバイスではなくIO Finalizerが署名します。デバイスのSignerロールは、確認できないものへの署名を求められるのではなく、それらをスキップします。表示される手数料も、v6トランザクションでは同じトランザクションでどちらのプールからも支出できるため、OrchardとIronwood両方の価値残高を合計するようになりました。
このプール会計を正しく行うことは、理論上だけでなく実務上も重要です。最近のBrave自身のZcashウォレットのバグは有用な例です。その手数料計算はすべてのシールド付き入力がレガシーOrchardプールに属すると仮定していたため、トランザクションが実際にはIronwoodを含む場合、アクションの重複と誤った手数料見積もりにつながりました。これはまさに、ハードウェアウォレット署名における「ホストを信用せず自ら再計算する」という原則が防ぐべき種類のエラーです。コンパニオンウォレットはプール会計を誤り、自ら計算を検証するデバイスだけが、署名前にそれを検知できます。
各署名者の現状
Ledgerは状況全体を変えました。 2026年9月23日、LedgerはLedger Wallet Desktop内でネイティブなシールド付きZcashサポートを出荷し、別個のコンパニオンアプリは不要になりました。支出鍵はデバイス上に残り、コンピューターがトランザクション計算を行い、画面上ですべてを承認してから署名されます。対応するのはIronwoodのみで、古いOrchardまたはSaplingプールには対応しません。欠点は、コンパニオンウォレット（Zkoolなど）を必要としたZondax製レガシー「Zcash Shielded」アプリが廃止されることです。Ledgerは11月5日にその古いアプリを利用不可にするため、現在も利用している人はそれまでに資金を移動する必要があります。
Keystoneは良好な状態です。 ファームウェア3.0.2は7月に完全なIronwoodサポートを追加しており、現在も安定版として必要です。ただし、何かに署名するにはその版以降が必要です。
Hitoは初期テストネットの節目を越えて進展しています。 実物ハードウェア上で初めて実際のOrchardからIronwoodへのトランザクションに署名・送信しました（当初はテストネット）。後続アップデートでは、本番ハードウェア上でのメインネットフロー（Ironwood→Ironwood、Ironwood→Transparent、その他）が確認されています。安定ファームウェアとより広範なリリースは引き続き進行中です。
ZondaxとZkoolは現在流動的です。ZondaxのアプリはLedgerで廃止されるものです。Ledgerデバイスと通信するためにそのアプリへ依存していたZkoolは、古いアプリが消えた後にその役割がどうなるかを示していません。今後もLedger利用者にとって関連性を保つのか、あるいは将来は主に他のデバイスとの関係になるのかは不明です。
移行自体が最大の波及効果です。プールをまたいで移る金額は公開されるため、ウォレットは一つの可視的なまとまりで残高を移動するのではなく、標準額面に分けて時間をかけて送金します。つまり移行ごとに多数のトランザクションへ署名する必要があり、ハードウェアウォレットでバッチPCZT署名が非常に重要だった理由です。
Ledgerのファームウェア作業もハードウェア制限に直面しました。実際のノート支出では、単一コマンドで数万件の暗号学的システムコールに達し、デバイスのウォッチドッグが作動することがありました。修正では有限体演算をソフトウェアへ移し、Nano Xのスタック制約内に収めるため共有スクラッチ状態が必要になりました。
https://forum.zcashcommunity.com/t/ironwood-is-here-updated-wallets-libraries-aug-20/56557/40
一枚で見る進化
