Midnightのシールド状態復旧、ウォレット運用で最大の課題に

Midnightの2026年3月のローンチは、プライバシー重視ウォレットにおける問いを実務上の問題に変えた。ユーザーがウォレットを復元する際、実際には何が復元されるのか、という問いである。

答えは必ずしも「すべて」ではない。MidnightのFAQによると、プライベートな状態は暗号化され、ローカルに保存される。シードフレーズは非シールドアドレスと公開履歴を復元できるが、それだけで未使用のシールドノートやプライベートなコントラクトデータを復元できるわけではない。このローカル状態が失われた場合、関連資産にアクセスできなくなる可能性がある。

これは、よく知られたアカウント型ウォレットのモデルよりも厳しい制約である。アカウントチェーンでは、ウォレットの復元は多くの場合、シードからアドレスを導出し、ノードに現在の残高を照会することを意味する。シールドシステムでは、chain上でcommitmentの存在は確認できても、暗号化されたcommitmentのうち、どれが復元中のユーザーに属するかは明らかにならない。復旧は、インデックス付けされたプライベート検索の問題となる。

Midnightのローンチ発表によれば、同ネットワークは2026年3月、プログラム可能なエンドツーエンドのプライベートアプリケーションに向け、状態の継続性と永続性を備えて稼働を開始した。ただし、状態の継続性にはウォレット側の帰結がある。ユーザーは、プライベートなchainオブジェクトに意味を与える状態を保持、再構築、または安全に再スキャンしなければならない。

Midnightの3月のネットワーク報告によると、mainnetのジェネシスブロックは2026年3月17日に作成された。この報告書は、プライベートsmart contractと資産向けの主要なウォレットインターフェースとしてLace、CTRL、1amを挙げている。したがって、その復旧設計は二次的なユーザー体験の細部ではない。スマートフォンの故障、古くなったノートPCのバックアップ、ウォレット移行、長期間のオフラインといった日常的な事態を経ても、プライベートな所有権が存続するかを左右する。

Chainにあるのは証拠であり、読める残高ではない

シールド送金は通常、複数の異なる痕跡を残す。

commitmentとは、資産額や所有権情報といったプライベートノートの内容を明かさずに、その値にコミットする公開chainオブジェクトである。nullifierは、そのノートが使用された時に公開される値である。ノートを直接特定せずに、同じノートが二重に使用されることを防ぐ。ウォレットはさらに、自身宛てのノートを認識し、後に有効な支出を作成するために必要なプライベートな情報を保持しなければならない。

したがってchainが確立できる公開された事実は2つある。commitmentが作成されたこと、そしてそのnullifierが過去に使用されていないことである。一般的な照会に対し、単純に「Aliceは42単位を保有する」と返すことはできない。その照会はプライバシーモデルを損なうためである。

復元されたウォレットは、シードから候補鍵を導出し、関連する公開chain履歴を取得し、暗号化された出力を調べ、どの出力を復号できるかを判断し、支出可能なノート集合を再構築し、それらのノートがいずれもnullifyされていないことを検証する必要がある。プライベートなコントラクト実行では、同じプロセスにwitness、暗号化状態、同期メタデータが加わる可能性がある。

重要なのは、公開されているが不透明なデータと、プライベートだが再構築可能なデータの区別である。commitmentとnullifierはネットワークから取得できる。Midnightのウォレット設計が適切な導出パスを公開していれば、シードから決定論的な鍵情報を導出できる。しかし、ウォレットには依然として、プライベート状態の暗号化記録、または履歴をスキャンしてそれを再作成する能力のいずれかが必要となる。

この境界を説明せずに、シードフレーズを完全なバックアップと呼ぶプロバイダーは、状態復旧ではなく、鍵復旧を説明しているにすぎない可能性がある。

4つの復旧ケース、4つの異なるリスク

最も単純なのは、最新の暗号化ウォレットバックアップを新しい端末で使うケースである。バックアップには、認識済みのノート、暗号化されたコントラクト状態、同期チェックポイント、ローカルメタデータが含まれる可能性がある。端末はパスワードまたは復旧鍵でこれを解除し、保存済みチェックポイントからchainの進捗を確認した上で、その先をスキャンする。これは高速だが、バックアップが集中的な標的となる。平文でコピーされれば、残高、相手方、アプリケーションとのやり取り、支出経路を露出する可能性がある。

第2は、シードのみの復元である。ウォレットは鍵を導出し、安全な開始高、おそらくジェネシスからスキャンする。これはプロバイダーがホストするバックアップへの依存を抑えるが、プライベートスキャンのコストを伴う。端末は、自身の暗号化出力を特定するために十分な公開履歴を取得しなければならない。クライアントが要求するブロック、フィルター、ノートをサーバーが観測すれば、ペイロードを復号できなくても、タイミング、ウォレットの経過年数、アプリケーション利用を推測できる可能性がある。

第3は、古いバックアップである。バックアップ時点で把握していたノートは含まれるが、それ以降の受領、支出、プライベートなコントラクト変更は欠けている。正しいウォレットは、ローカルのノート一覧を最終的なものとして扱うことはできない。チェックポイント以降の公開状態を再生し、新たな暗号化ノートを特定し、古いノートがnullifyされたかを検証する必要がある。そうしなければ、古い残高を表示したり、ネットワークに拒否される支出を試みたりするおそれがある。

第4は、ウォレットプロバイダー間の移行である。ここでの復旧は可搬性に依存する。ウォレットBはウォレットAと同じアドレスを導出できるのか。ウォレットAから暗号化されたプライベート状態をインポートできるのか。互換性のある閲覧情報を用いて完全スキャンを実行できるのか。デプロイ済みアプリケーションとやり取りするために必要なコントラクトwitnessを再現できるのか。プロバイダー固有のバックアップしかサポートしないプライベートシステムは、暗号技術を維持していても、実質的なカストディーの囲い込みを生み出しかねない。

ローカル状態はセキュリティ境界の一部

MidnightのFAQは、その帰結を異例なほど明確に述べている。ローカルのプライベート状態を失えば、シールド資産にアクセスできなくなる可能性がある。ここから、有用なアーキテクチャ原則が導かれる。ローカルデータベースを、使い捨て可能なキャッシュではなく、セキュリティ上の対象物として扱うべきである。

再計算可能であるべき状態もある。

難しいのは、プライベートノートとコントラクトの層である。ウォレットは、支出に必要なすべての要素が公開ノードの応答から再作成できると想定してはならない。プライベートなコントラクト状態がユーザー向けに暗号化され、ローカルにしか保存されていない場合、復旧には、復元可能な暗号化コピー、決定論的な導出手順、またはそれを再作成できるchain履歴スキャンが必要となる。

「witness」という言葉には正確さが求められる。witnessとは、ある命題が真であることを証明者が示すために使うプライベートな証拠である。シールド支出では、どのcommitmentを支出するかを明かさずに、認証済み構造内にノートcommitmentが含まれることを立証できる。proofはプロトコル境界を越える。witnessは越えるべきではない。

Walletsecret key • note • witness • private contract inputs

zero-knowledge proof and public transaction data

Midnight validator

No private witness transmitted

これは復旧に直接的な影響を及ぼす。クラウドバックアップが安全に保持できるのは、クラウドプロバイダーがアクセスできない鍵情報で暗号化されたデータのみであり、リモートでの復号やproof生成の役割を持ってはならない。プロバイダーが支出鍵にアクセスできる、または有効な支出の生成を支援できるなら、単にバックアップを保存しているのではない。実質的な共同カストディアンになっている。

閲覧鍵は一つの問題を解決し、別の問題を生む

FAQは閲覧鍵の開示についても説明している。閲覧鍵により、第三者は完全な支出権限を受け取ることなく、選択されたプライベート情報を確認できる。これは税務報告、監査、顧客サポート、委任業務、機関向け統制に有用である。

ただし、コストなしのプライバシー機能ではない。閲覧鍵には範囲がある。ウォレット設計者は、受取送金、送付送金、資産タイプ、取引時刻、残高、コントラクト操作、あるいは限定された一部だけのどれを露出するのかを定義しなければならない。また、開示を実務上取り消せるかも決めなければならない。受領者が復号済みの記録をコピーすれば、後から取り消してもそのコピーを消すことはできない。

復旧システムは、少なくとも以下の3種類の認証情報を分離すべきである。

1. 支出権限。有効な支出を作成できる。
2. 閲覧権限。定義されたプライベート活動を復号または認識できる。
3. バックアップ権限。ユーザー端末の外部で、最初の2つのいずれかを自動的に与えることなく、暗号化状態を復元できる。

この3つをシードのみのエクスポートにまとめるのは簡単だが、被害範囲を広げる。分離すれば選択的開示を支援できる一方、鍵管理の複雑さと復旧失敗の形態は増える。

DUST委任には明確な復元手順が必要

Midnightは取引モデルでDUSTを使用しており、FAQはシステムの公開commitment、nullifier、アドレスの仕組みと並べてDUSTを説明している。ユーザーがDUSTをアプリケーションに委任し、その間にもchainが進行を続ける場合、ウォレットは静的な残高以上のものを追跡しなければならない。

復旧経路は、委任関係、現在の認可条件、消費済みリソース、保留中のアプリケーション操作、取り消しまたは満了の状態を特定すべきである。これらのオブジェクトがプライベートなら、古いバックアップを信頼できるものと見なすことはできない。復元されたウォレットは前方にスキャンし、公開commitmentとnullifierの変化に照らしてローカルビューを照合しなければならない。

ここでは、アプリケーションウォレットがベースウォレット以上の情報を漏らす可能性もある。汎用ウォレットは所有するノートをスキャンする場合がある。一方、アプリケーション統合型ウォレットは、特定のコントラクト、リソースパターン、または直近の操作を狭く絞って照会する可能性がある。proof層でプライバシーが保護されていても、周辺の同期、インデックス作成、テレメトリーが同じ履歴を別の場所で再現しない場合に限られる。

支援付き復旧はカストディーの判断

防御可能な復旧モデルはいくつかあるが、それぞれが異なるリスクを交換する。

シードのみの復旧はプロバイダーへの依存を減らすが、スキャンに時間がかかる可能性があり、復旧不能なプライベート状態がバックアップされていなかった場合には失敗するおそれがある。

暗号化ウォレットバックアップは復元速度を高め、ローカル状態を保持するが、暗号化設計、パスワード復旧プロセス、バックアップの可搬性がセキュリティ上の重要事項となる。

閲覧鍵による復旧は監視と照合を助けるが、支出復旧と混同すべきではない。

支援付き復旧では、サービスが暗号化された断片を保持したり、状態の特定を支援したりできるが、復元を支援するというだけでサービスがユーザーの取引グラフを知ることがないよう、プロトコルは設計されなければならない。

ソーシャルまたは機関カストディーは、復旧権限を保護者またはポリシー署名者に分散することで、単一端末の障害を軽減できる。一方で、可用性リスク、共謀リスク、暗号技術だけでは解決しないガバナンス上の問題が加わる。

この件で提示された唯一の外部反応は、敵対的というより慎重なものだった。フォーラム投稿で、Bitroveの創業者であるJamesは実務的な疑問を提起した。Midnightのプライバシー優先エスクローモデルを支持する一方、ウォレット対応、ハードウェアウォレット互換性、トークンの利用可能性、エコシステムの成熟度について質問した。利用可能な資料には反対意見は示されていない。

ウォレットチームにとって、本番運用の試験は具体的である。シードだけから復元する。90日前の暗号化バックアップから復元する。ノートを受け取り支出した後に復元する。DUST委任が変化した後に復元する。異なるウォレット実装に復元する。それぞれのテスト中に発生するすべてのネットワーク要求を記録する。

ウォレットが資金を復元しても、ユーザーの取引履歴全体をインデクサーに明かしたなら、復旧は成功し、プライバシーは失敗したことになる。