過去1週間（2026/06/01 - 2026/06/07）、ブロックチェーンエコシステム全体にわたって複数の攻撃インシデントが観測されました。今週のレポートでは、ZcashのOrchardシールドプールにおける深刻なサウンドネス脆弱性の公式開示に焦点を当てます。この脆弱性により、ZECの検出不可能な偽造が可能になり得ました。オンチェーンでの悪用は確認されていませんが、この開示により緊急ネットワークアップグレードが実施され、ZECの価値は40%以上下落しました。
| 日付 | インシデント | 種別 | 推定損失 |
|---|---|---|---|
| 2026/06/04 | Zcash Orchard | ZKサウンドネスバグ | 悪用は確認されず |
Web3向けベストセキュリティ監査企業
ローンチ前に設計・コード・ビジネスロジックを検証する
今週のハイライト：Zcash Orchardサウンドネスバグ
このインシデントを今週のハイライトとして選んだのは、本番環境で発見されたZK脆弱性の中でも最も深刻なものの一つであるためです。回路の制約が一つ欠如していたにもかかわらず、複数の監査を経て4年以上にわたって検出されず、最終的にAI支援によるセキュリティレビューで発見されました。この脆弱性クラス（ZK回路における制約不足のリレーション）は、ZK回路上に構築されたあらゆるプロトコルに存在し得ます。
2026年6月4日、ZcashはそのOrchardシールドプール回路における深刻なサウンドネスバグを公式に開示しました [1]。ゼロ知識証明回路における制約の欠如により、二重支払いを防ぐ暗号的バインディングが破壊され、同じシールドノートを検出されることなく複数回使用できる可能性がありました。この脆弱性は2022年5月のOrchard有効化以来存在しており、2026年5月29日にセキュリティ研究者Taylor HornbyがAI支援監査によって発見しました。緊急ネットワークアップグレード（NU6.2）により、2026年6月3日に回路が修正されました。悪用された証拠は見つかっていません。
背景
Zcashはプライバシー重視のLayer-1ブロックチェーンであり、ネイティブトークンはZECです。すべてのトランザクション詳細が公開されているBitcoinとは異なり、Zcashはゼロ知識証明によるシールドトランザクションをサポートし、送信者アドレス・受信者アドレス・トランザクション金額を隠蔽します。Zcashには複数のシールドプールがあり、それぞれプライバシープロトコルの異なる世代に対応しています。Orchardは最新世代であり、2022年5月のNU5ネットワークアップグレードで有効化され、トランザクションの検証にhalo2ゼロ知識証明システム [2] を使用しています。ユーザーがシールドトランザクションを行う場合、そのユーザーは証明者として機能します。つまり、Orchard回路を使用してゼロ知識証明を構築し、トランザクションが有効であること（ノートを所有していること、ヌリファイアが正しく導出されていること、金額が釣り合っていること）をプライベートな詳細を明かさずに証明します。ネットワークノードは検証者として機能し、基礎となるデータを見ることなく証明を検証します。Orchard回路は、有効なすべての証明が満たすべき制約を定義します。この脆弱性はその回路実装にあり、Zcashの4つのコアコンセプト（鍵・アドレス・ノート・ヌリファイア）が関係しています。
鍵。 Zcashの鍵階層は、ほとんどのブロックチェーンよりも複雑です。単一のスペンディングキー（ウォレットのシークレット）から複数のサブキーが導出されます：ask（スペンド認証秘密鍵）、nk（ヌリファイア導出鍵）、rivk（ランダマイザー）。これらから、ak（認証公開鍵）とivk（受信ビューイングキー、ivk = Commit(ak, nk, rivk)）が計算されます。ivkは着信する資金を識別・受信するために使用されます。
アドレス。 Orchardアドレスを作成するために、ユーザーはダイバーシファイアd（11バイト値）を選択し、これによりダイバーシファイドベースポイントg_d = DiversifyHash(d)が決まります。アドレスはペア(d, pk_d)であり、ダイバーシファイド送信鍵pk_dは楕円曲線スカラー乗算として計算されます：pk_d = [ivk] g_d。これはアドレスがユーザーのビューイングキーに暗号的にバインドされていることを意味します。
ノート。 ノートとは、受け取った資金を表す資産レコードです。プライバシーのために、オンチェーンに保存されるのはノート自体ではなく、ノートコミットメントcm（pk_d・値・その他のデータを含むノートの内容への暗号的コミットメント）です。ノートは受信者のアドレスにロックされています。
ヌリファイア。 ノートを使用する際、使用者はヌリファイアnfを公開します。これはノートのデータとヌリファイアキーnkから計算されます：nf = Extract_P([(F_nk(ρ) + ψ) mod p]G + cm)。重要なセキュリティ特性は、各ノートが厳密に一つのヌリファイアを生成しなければならないということです。ヌリファイアがオンチェーンに現れると、対応するノートは永久に使用済みとみなされます。同じノートが異なるヌリファイアを生成できれば、誰にも気づかれることなく複数回使用される可能性があります。
バインディングチェーン。 これらのコンセプトは暗号的バインディングチェーンによって結びついています：
赤くハイライトされたノード（pk_d、nk）は、脆弱性がバインディングチェーンを破壊するポイントです。回路はpk_d = [ivk] g_dを強制する必要があります。これにより使用者が正しいivkに、そしてそのノートに対する正しいnkにバインドされます。このバインディングが破壊されると、使用者は偽のivkを偽造し、各使用で異なるnkを使用できます。異なるnkの値は同じノートに対して異なるヌリファイアを生成し、二重支払いを可能にします。
回路がこのバインディングをどのように強制するか。 リレーションpk_d = [ivk] g_dは楕円曲線スカラー乗算（Q = [k]P）であり、ダブルアンドアドアルゴリズムを使用して実装されます。ゼロ知識回路では、検証者はアルゴリズムを直接実行するのではなく、回路がすべての中間ステップを制約します。正しいスカラー乗算回路は、特に内部ループのベースポイントが意図された入力ベースポイントと等しいこと（P_loop = P_input）を強制しなければなりません。この制約がなければ、回路は有効なスカラー乗算が実行されたことを証明できますが、それが誤ったベースポイントで行われた場合、バインディングチェーン全体が意味をなさなくなります。
脆弱性の分析
脆弱なECCガジェットは、pk_d = [ivk] g_dを強制するスカラー乗算リレーションで使用されていました。ここでQ = pk_d、k = ivk、P = g_dです。脆弱なコードはhalo2リポジトリの変数ベーススカラー乗算実装（incomplete.rs L309-L310）に存在します：
// incomplete.rs (完全なソースは上記リンク参照)
298 for (row, k) in bits.iter().enumerate() {
299 // z_{i} = 2 * z_{i+1} + k_i
...
305 z = region.assign_advice(|| "z", self.z, row + offset, || z_val)?;
306 zs.push(Z(z.clone()));
307
308 // `x_p`、`y_p` を割り当てる
309 region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?; // BUG
310 region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?; // BUG
311
312 // ビットが設定されている場合は `y` を使用、設定されていない場合は `-y` を使用
313 let y_p = y_p
314 .zip(k.as_ref())
315 .map(|(y_p, k)| if !k { -y_p } else { y_p });
316
317 // lambda1 を計算して割り当てる
318 let lambda1 = y_a.zip(y_p).zip(x_a.value()).zip(x_p)
.map(|(((y_a, y_p), x_a), x_p)| (y_a - y_p) * (x_a - x_p).invert());
...
}ゼロ知識回路では、証明者はすべてのセル値を入力します。回路自体はセル間で値をコピーしたり転送したりできません。回路は検証者がチェックする制約のみを定義できます。BUGとマークされた2行は、assign_advice()を使用してベースポイント座標x_pとy_p（ウィットネス値として知られるプライベート回路入力）を回路のアドバイス列（証明者のプライベート入力領域）に書き込みます。この関数は、外部のベースポイントに紐付ける制約を作成することなく値を入力します。すべてのループ反復にわたってベース値が等しいことを保証する別の制約は存在します（証明者は各反復で異なるベースポイントを使用できません）。しかし、証明者はすべての反復にわたって任意の単一ベースポイントを代入でき、外部から渡された実際のg_dにループのベース値をアンカーする制約が存在しないため、回路はそれを拒否しません。
正しい関数はcopy_advice()であり、これは値を入力しかつ実際のベースポイントg_dと一致することを強制する等式制約（コピー制約）を追加します。g_dはアドレスごとに異なる（各アドレスのダイバーシファイアから導出される）ため、回路はそれをハードコードできません。ループのベースポイントを上流で計算されたg_dと一致するよう制約しなければなりません。
その結果、回路は実際にはpk_d = [ivk] g_dを強制していませんでした。悪意のある証明者は、ループ内で任意のベースポイントを（正しいg_dの代わりに）供給でき、回路はその証明を受け入れ続けました。内部計算は代数的に自己整合していましたが、プロトコルで指定されたダイバーシファイドベースポイントにアンカーされなくなっていました。この余分な自由度により、証明者は毎回異なるnkを選択し、対応するivk = Commit(ak, nk, rivk)を計算し、制約されていないスカラー乗算を使って偽造したivkを通過させることができます。ヌリファイアはnkに依存するため、各使用で異なるヌリファイアが生成されます：
同じノートN + nk_1 → nf_1
同じノートN + nk_2 → nf_2
ここで：nf_1 ≠ nf_2コンセンサスはヌリファイアがすでにオンチェーンに現れているかどうかのみをチェックします。各使用で一意の正当に見えるヌリファイアが生成されるため、二重支払いはネットワークから見えません。
修正 [3] では、ループの最初の反復（row == 0）にcopy_advice()呼び出しを追加し、ループのベースポイントを外部から渡された実際のbaseにアンカーするコピー制約を作成します。残りの反復は引き続きassign_advice()を使用しますが、既存の反復間整合性制約がアンカーをすべての反復に伝播します。
影響と対応
悪用シナリオ。 悪意のある証明者はこの脆弱性を悪用して、同じOrchardノートを複数回使用し、毎回異なるヌリファイアを生成することができます。ゼロ知識証明がプライベート回路入力を隠蔽するため、不正なヌリファイアは正当なものと区別がつきません。この攻撃はオンチェーンに決定的な暗号的証拠を残さないため、実際に悪用されたかどうかを確実に判断することは不可能です。
この脆弱性は2022年5月のOrchard有効化（NU5アップグレード）以来存在しており、合計4年以上の露出期間がありました。Zcashのターンスタイル会計は、Orchardプールから透明またはSaplingプールへ流出できる偽造価値の量を制限し、より広いサプライへの実現した影響を抑制します。しかし、偽造ノートはシールドプール内に検出されずに存在する可能性があり、そのプライバシー特性により、脆弱性が実際に悪用されたかどうかを暗号的に証明することは不可能です。
注意：ターンスタイルはプールの総流出が総流入を超えた場合にのみ作動します。攻撃者はこの制限に達することなく、偽造価値を少額ずつ長期にわたって引き出すことができます。この不一致は、正当なユーザーが集合的にプールが実際に保有している量以上を引き出そうとした場合にのみ明らかになります。
発見と対応。 この脆弱性は2026年5月29日、セキュリティ研究者Taylor Hornby（Shielded Labsとの契約）が前日リリースされたAnthropicのOpus 4.8モデルを使用したAI支援監査フレームワークにより発見しました。旧モデルを使用した同じ回路の以前の監査ではバグが発見されていませんでした。HornbyはZODLに同日問題を報告しました。6月2日（UTC）の緊急ソフトフォークにより一時的にOrchardトランザクションが無効化され、6月3日（UTC、ブロック3,364,600）のNU6.2ネットワークアップグレードにより修正された回路が導入され、Orchard機能が回復しました [1]。6月4日の公式開示後、ZECは価値の40%以上を失い、清算額は1億ドルを超えました [4]。
結論
Zcash Orchardの脆弱性は、スカラー乗算回路における等式制約の欠如により引き起こされ、証明者がベースポイントバインディングをバイパスし、ヌリファイアを偽造して二重支払いを行うことを可能にしました。コードレビューやテストによって発見できることが多い従来のスマートコントラクトのバグとは異なり、ZK回路のサウンドネスバグは、回路が実際に証明することと、証明すべきことのギャップを理解することが必要です。この微妙な点が、専門的な暗号学者による4年以上のプロフェッショナル監査を逃れました。
halo2ライブラリはZKPエコシステム全体で使用されており、同様の制約不足のリレーションがこれらの暗号的構成要素上に構築された他のプロジェクトにも存在する可能性があります。ゼロ知識証明を使用するプロトコルは、未発見のサウンドネスバグの潜在的な影響を限定するためにバランス整合性チェック（ターンスタイル会計など）を実装すべきです。Zcashのターンスタイルメカニズムなしでは、シールドプール内で作成された偽造価値がより広いサプライに自由に流入していた可能性があります。Shielded Labsは、Orchard回路を数学的に形式検証する計画を発表しました。
この発見は、ヒューマン・イン・ザ・ループワークフローの典型的な例です。経験豊富なセキュリティ研究者が監査フレームワークを構築して調査を指揮し、AIが個々の回路制約のチェックを広範に担当しました。どちらの要素も単独では十分ではありませんでした。旧モデルによる以前のAIのみの実行ではバグを見逃し、専門家による何年もの人間によるレビューも同様に見逃しました。HornbyはZcashのセキュリティ専門家であり、AIが活動する適切な監査スコープを設計するためにドメインの専門知識が必要でした。BlockSecが最近発表した研究 [5] でも示されているように、AIモデルはセキュリティ分析において急速な進歩を遂げていますが、AIを適切なターゲットに向け、発見したものを検証するための専門家の指導はまだ必要です。専門家とAIの間の双方向的な協力（AIのみに依存するのではなく）が、最も効果的な作業モデルです。
参考文献
- The Orchard counterfeiting vulnerability and next steps, Zcash Community Forum, June 4, 2026. リンク
- halo2: A zero-knowledge proof system, GitHub. リンク
- Fix: anchor scalar multiplication base point via copy constraint, halo2 GitHub. リンク
- Why ZEC fell 40% even after Zcash patched a shielded pool bug, CoinTelegraph, June 5, 2026. リンク
- Re-Evaluating EVMBench: Are AI Agents Ready for Smart Contract Security?, arXiv, 2026. リンク
BlockSecについて
BlockSecはフルスタックのブロックチェーンセキュリティおよび暗号資産コンプライアンスプロバイダーです。私たちは、コード監査（スマートコントラクト・ブロックチェーン・ウォレットを含む）の実施、リアルタイムの攻撃迎撃、インシデント分析、不正資金の追跡、AML/CFT義務の履行を、プロトコルおよびプラットフォームのライフサイクル全体にわたって顧客が行えるよう支援する製品・サービスを構築しています。
BlockSecは複数のブロックチェーンセキュリティ論文を著名な学会で発表し、DeFiアプリケーションのゼロデイ攻撃を複数報告し、複数のハッキングをブロックして2000万ドル以上を救済し、数十億ドルの暗号資産を保護してきました。
-
公式ウェブサイト：https://blocksec.com/
-
公式Twitterアカウント：https://twitter.com/BlockSecTeam
