エンジニアリング集団のEryxが2026年7月14日、SecondFiの資金回収を題材にしたゼロ知識証明の概念実証（PoC）を公式Xで紹介しました。コードはオープンソースのリポジトリ key-recovery-POC で公開されています。
発想はこうです。SecondFiのインシデントで秘密鍵が広く露出してしまった今、「鍵を見せる」ことでは所有者を証明できません。まだ秘密のまま残っているのは、その鍵の元になった復元フレーズ（ニーモニック）だけです。そこで、復元フレーズそのものを一切明かさずに「自分はこの露出した鍵を導く復元フレーズを知っている」ことだけを証明し、その証明に送金先を結びつける。Eryxは、これが可能であることを示すPoCを作った、と説明しています。
本稿の結論を先に述べます。この試みは、資金回収という難題を検証可能なコードとして開いた価値ある一歩です。2026年7月15日時点の公開コードとCardanoの標準仕様（CIP-3・CIP-1852）を照合すると、PoCがどの範囲をまず形にし、実用化に向けてどの論点が次の公開検証になるかが見えてきます。以下では、その発想の有用性と、コードが具体化した次の検証テーマを整理します。
本稿は、リポジトリのmain、コミット 2180fe8c24781325e20c2bf0c9911fda6d116b0a を基準にしています。
なぜ「漏洩した秘密鍵」では所有者を証明できないのか
まず、今回の発想がどんな問題を解こうとしているのかを押さえます。
Eryxの整理によれば、SecondFiのインシデントでは、取引に署名したことのある利用者の秘密鍵が露出しました。ホワイトハットが、残った資金を安全なウォレットへ退避させたものの、次の課題として「その資金を本当の所有者へどう返すか」が残ります。ここが難所です。
秘密鍵がすでに公になっているなら、「鍵を持っていること」は所有の証明になりません。誰でもその鍵を提示できてしまうからです。
一方で、鍵は復元フレーズから一方向に作られます。復元フレーズから鍵は計算できますが、鍵から復元フレーズは復元できません。つまり、露出したのは鍵であっても、その手前にある復元フレーズはまだ本人しか知らない、という状態があり得ます。
そこでEryxのPoCは、この「一方向性」を所有証明の土台に使います。復元フレーズを明かさずに、「自分はこの鍵を導く復元フレーズを知っている」ことだけをゼロ知識で証明しよう、という方向です。
この着眼点自体は妥当です。漏洩後の所有者識別という、回収でもっとも難しい部分に、素直な角度から切り込んでいます。
なお、この「最悪ケースでも残るかもしれない回収オプション」という論点は、SIPOでも6月末に一度扱っています。当時はチャールズ・ホスキンソン氏が自身でGroth16検証器をCardano Preview上で動かし、復元フレーズの保有証明とスマートコントラクトからの払い出しを試した、という内容でした。今回のEryxの公開は、その「証明を作る側の回路」を、独立したかたちでオープンソースとして差し出したもの、と位置づけると理解しやすくなります。Eryx自身も「派生プロトコルを考案したのではなく、それを拡張して回路を構築した。すべてオープンソースだ」と述べています。
EryxのPoCが目指す証明のかたち
Eryxの説明にもとづくと、目指している証明はおおむね次のようなものです。
- 秘密の入力（witness）として、24語の復元フレーズを回路に与える。
- 現行回路は、そこから計算した96バイトの
master_keyを公開出力にする。 - 公開入力の
cardano_addressは回収先アドレスとして証明に結びつけ、第三者による請求先の差し替えを防ぐ方向を示す。 - ただし現行回路は、
master_keyから侵害された元アドレスまでの派生を証明していない。したがって、現在のコードだけで「この侵害アドレスを導く復元フレーズを知っている」と完結して証明できるわけではない。
Eryxはこれを、Groth16というゼロ知識証明の方式で実装したと説明しています。ねらいは、「シードフレーズは公開しない。信頼も要らない。誰でも検証できる数学だけで所有を示す」という状態です。
そしてEryx自身、投稿の中で「これは概念実証であり、すぐに使えるツールではない」とはっきり述べ、「フル回路は書き換えではなく設定の変更で到達できるが、それを実用に足るものへ強化する作業こそ、オープンな場で行うべきだ」として、レビュー・Issue・PRを歓迎しています。
ここからは、Eryxが公開したPoCを出発点に、現行実装が形にした範囲と、コミュニティによる検証・発展の余地を確認します。
このPoCがもたらした3つの貢献
このPoCがもたらした貢献は、大きく3つあります。
第一に、回収先アドレスを証明の公開入力に組み込むという設計方向です。証明が特定の回収先に紐づいていれば、第三者が証明を使い回して別の宛先へ資金を誘導することを防ぎやすくなります。回収を「横取りされない」ようにする、という発想は理にかなっています。
第二に、オープンソースで公開したこと自体です。回路とスクリプトが誰でも読める状態にあるため、第三者が仕様と実装を突き合わせ、問題点を指摘できます。実際、本稿の指摘も、公開されたコードを読めたからこそ書けています。
第三に、「漏洩した鍵ではなく、その手前の復元フレーズを所有証明に使う」という着眼点の健全さです。これは、漏洩後の回収という難題に対する、地に足のついた方向づけです。
このPoCの意義は、回収という難題を具体的な回路と公開議論へ進めたことにあります。現行実装はその第一段階を形にしており、ここからどの要素を回路内へ取り込むかが次の検証テーマになります。
実用化へ向けて開かれた5つの検証ポイント
以下は、2026年7月15日時点の公開コードをCardanoの標準仕様と照合することで具体化した、実用化へ向けた5つの検証ポイントです。コードが公開されたことで、次に何を確かめ、どこを発展させるかを共通の論点として議論できます。
1. 侵害アドレスまでの派生を、次の段階でどう組み込むか
第一の検証ポイントは、復元フレーズから得られる master_key と、侵害されたCardanoアドレスへの派生（BIP-32／CIP-1852の子鍵導出）を、次の段階でどう結びつけるかです。
これはリポジトリのREADMEと回路コード自身が明記しています。READMEの「Disclaimer」には、「回路は現時点で master_key から侵害されたCardanoアドレスへの完全な派生パスを証明しない。その結びつきはアプリケーション層で検証する必要がある」とあります。
現行PoCでは、この結びつきはアプリケーション層で検証する構成です。実際の回収フローへ進む際には、対象アドレスまでの派生を回路内へ取り込むか、外部検証とどう安全に組み合わせるかが主要な統合テーマになります。
2. master_key の公開出力をどう扱うか
回路では、96バイトの master_key が公開出力（public output）として宣言されています。
Cardanoの鍵導出仕様（CIP-3）において、96バイトの鍵は、64バイトの拡張秘密鍵と32バイトのチェーンコードから成る、ルートの拡張秘密鍵（XPrv）に相当します。つまりこれは、復元フレーズと並んで、もっとも秘匿すべきルート秘密情報です。
現行回路では、その位置にある値を公開信号として扱います。後述するように、現在の導出は実ウォレットと一致しないため、いま出力される値がそのまま実ウォレットのルート鍵になるわけではありません。実ウォレット相当へ拡張する段階では、何を公開信号とするか、ゼロ知識性とどう両立させるかを公開レビューで慎重に確認するテーマになります。
3. Icarus方式との整合をどう進めるか
YoroiやDaedalusなどで採用されてきたIcarus方式は、PBKDF2-HMAC-SHA512を使ってルート鍵を導出します。CIP-3のIcarus仕様では、リカバリー用のシード相当をソルト（salt）に、任意のパスフレーズをパスワード（password）に置き、4096回反復して96バイトを出力し、その後ビット調整を行います。
一方、現行回路のPBKDF2は、264ビットの復元フレーズ列をパスワードに、ソルトは空、反復回数は1回、という設定になっています。回路コード上のコンポーネント呼び出しは PBKDF2_HMAC_SHA512(264, 768, 1) で、コメント自体は「本来は4096回」を意図している旨を残していますが、実際に動くコードは1回です。
この構成では、パスワードとソルトの役割、ソルトの有無、反復回数がCIP-3のIcarus方式と異なります。公開サンプルのニーモニックを使った独立計算でも、両方式の出力が異なることを再現しました。現在は計算規模を抑えたPoC向け構成であり、実ウォレットと同じ鍵を導くためのIcarus方式との整合が、次の検証対象になります。
4. 本番規模へ拡張する際の計算コスト
いま実際に動くPoCは、反復回数1回・約31.6万制約の開発用構成です（READMEに記載。この規模なら 2^21 のパラメータファイルで足りるとされています）。
反復回数を4096回へ拡張すると、制約数は概ね比例して増えます。単純計算では10億規模（約13億制約）に達し、必要なトラステッドセットアップも 2^21 から10ビットぶんほど大きくなる見積もりです。設定変更を出発点として、証明生成コストとセットアップ規模をどのように現実的な構成へ落とし込むかが、実用化に向けた検討テーマになります。
さらに、最初の検証ポイントで述べた派生パスを回路内へ取り込む場合は、反復回数の調整と並行して回路ロジックを拡張することになります。現行PoCが基準点を示したことで、この追加実装の範囲も具体的に議論できます。
5. テスト・監査・秘密情報の扱いをどう強化するか
Eryx自身がREADMEで、「これは概念実証であり、第三者による十分なセキュリティ監査なしに本番利用してはならない」と明記しています。加えて、内部で使うSHA-512実装について「本プロジェクトとしてはテストベクタに対する独立検証を行っていない」とも述べています。
秘密情報の扱いも、PoCから実用段階へ進む際の重要な検証対象です。入力生成スクリプトは、復元フレーズを平文のJSONファイル（recovery_input.json）から読み込み、コンソールへ全単語を表示します（Mnemonic: に続けて語を並べる行があります）。READMEもファイルの秘匿を促しています。実運用では、安全な入力方式へ置き換え、復元フレーズをファイルやログへ残さない設計へ強化することが求められます。
PoCを次の段階へ育てるために
このPoCが公開されたことで、実際の回収へ近づけるための作業が、次のロードマップとして具体的に見えるようになりました。
- 回路の修正：復元フレーズから対象アドレスまでの派生（CIP-1852の導出パス）を回路内で証明する。
- 導出方式の整合：PBKDF2の役割・ソルト・反復回数をCIP-3のIcarus方式に合わせ、実ウォレットと同じ鍵を導けるようにする。
- 公開出力の再設計：ルート鍵に相当する値を公開信号として出す必要が本当にあるのかを見直す。
- テストベクタの整備：SHA-512やPBKDF2を含め、既知の入出力で正しさを検証する。
- 独立監査：ゼロ知識回路は誤りが壊滅的になりやすいため、第三者による監査を通す。
- 信頼できるセットアップ：本番規模の制約数に見合ったトラステッドセットアップ（MPCセレモニー）を用意する。
- 公式回収フローとの統合：影響判定、資格条件、払い出しコントラクト、監査結果と結びつけ、公式の回収手順の一部として位置づける。
6月末のホスキンソン氏の説明でも、概念実証から本番システムまでは「数週間ではなく数か月」かかり、監査が先である、という線引きが繰り返されていました。今回のPoCは、その工程を具体化し、公開の場で前へ進めるための出発点にあたります。
利用者が現時点で守るべき安全線
もっとも重要な実務上の注意です。
公式な回収手順が正式に案内されるまで、実際の復元フレーズを、このPoCや第三者のサイト・チェッカー・フォームへ入力しないでください。前述のとおり、現行のPoCは復元フレーズを平文で扱う構成です。オープンソースであることは監査可能性を高めますが、それ自体が安全性の保証ではありません。
回収に関する対応は、SecondFiなど関係主体の公式案内を確認してください。DM、検索広告、非公式QRコード、「確認のため」と称して署名や復元フレーズ入力を求める導線には応じないでください。復元フレーズ・秘密鍵・ウォレット認証情報は、いかなる相手にも共有しないことが大前提です。
まとめ：検証可能なコードから始まる、資金回収への新しい道筋
EryxのPoCは、「漏洩した鍵ではなく、その手前の復元フレーズで所有を示す」という回収の核心に、具体的なコードで踏み込みました。そして何より、それをオープンソースで公開しました。
これは、最悪ケースの回収という難題を、「私を信じてください」から「数学を確認してください」へ動かす一歩です。現行実装が最初の回路を形にしたことで、派生パス、Icarus方式との整合、公開出力、計算規模、テスト・監査といった次の検証テーマが具体的になりました。これはコードが公開されたからこそ可能になった前進です。
Eryxは完成品として閉じるのではなく、誰もが検証・提案・改良できる公開プロセスを始めました。秘密鍵漏洩後の資金回収という難題に対し、暗号技術とオープンな協働を結びつけたこの試みは、有用で興味深い出発点です。この検証可能なコードが、確認できる制度としての回収へ育っていく過程にも注目したいと思います。
参考・出典
- Eryx / key-recovery-POC（基準コミット
2180fe8）
https://github.com/eryxcoop/key-recovery-POC/tree/2180fe8c24781325e20c2bf0c9911fda6d116b0a - Eryx公式X投稿（2026年7月14日。参照リンクは公式アカウント）
https://x.com/eryxcoop - Cardano CIP-3（Wallet Key Generation／Icarus鍵生成）
https://cips.cardano.org/cip/CIP-3 - Cardano CIP-1852（HD（BIP-32）派生パス）
https://cips.cardano.org/cip/CIP-1852
SIPO関連記事
- チャールズ・ホスキンソン氏動画「Update」解説・全翻訳：SecondFi救済の最悪ケース設計、Groth16、そしてウォレット信頼回復への分岐点
https://sipo.tokyo/post-46439/ - SecondFi流出事件、ウォレット認証、そしてCardanoが向き合うべき利用者保護
https://sipo.tokyo/post-46350/
透明性メモ
本稿は、リポジトリのmainがコミット 2180fe8c24781325e20c2bf0c9911fda6d116b0a である状態を、2026年7月15日（JST）に確認して作成しました。Eryxの2026年7月14日のX投稿本文（提供された投稿記録）、リポジトリのREADMEと回路コード、Cardano CIP-3・CIP-1852を主な情報源としています。Xについては投稿固有URLを確認できなかったため、参考欄では公式アカウントへリンクしています。
情報の区分：（事実）派生パスを証明しない旨・master_key が公開出力である旨・PBKDF2の引数・約31.6万制約・SHA-512未検証・平文JSON入力とコンソール出力は、README・回路コード・スクリプトから直接確認しました。（ソース側の主張）「設定の変更で到達できる」「レビュー・Issue・PR歓迎」はEryxのXスレッド上の発言であり、コード事実として独立検証したものではありません。（評価）Icarus方式との不一致や公開出力への懸念は、公開コードをCIP標準と照合した結果です。
検証は静的なコード照合と公開仕様の突き合わせに加え、リポジトリに含まれる公開サンプルを使ってPoC方式とCIP-3のIcarus方式を独立計算し、出力の不一致を再現しました。フル証明生成、依存関係のインストール、本番4096回回路の実行は行っていません。実際の復元フレーズも一切入力していません。反復回数を4096回に戻した場合の「約13億制約」は、31.6万制約からの単純な線形見積もりであり、実測値ではありません。
本稿は技術解説であり、金融助言・法的助言・セキュリティ助言、および公式の回収手順ではありません。特定ウォレットの安全・危険、資産の回復可否を断定するものでもありません。実際の対応は、独立監査と各機関の公式案内を確認してください。復元フレーズ・秘密鍵・ウォレット認証情報は、いかなる相手にも共有しないでください。