Midnightのシールド台帳が突きつけるインフラ課題：監視システム化せずにウォレットはいかにプライベート状態を見つけるか

Midnightのプライバシーに関する約束は、暗号化とゼロ知識証明から始まる。しかし、より難しい本番運用上の課題はその直後に生じる。ウォレットは依然として自分の資金を見つけなければならない。

The Blockが報じたように、Cardano創設者のCharles Hoskinsonがプライバシー保護型partner chainとしてMidnightを発表した際、焦点となったのはチェーンの暗号技術だった。しかし、稼働中のプライバシーネットワークは、より実務的な問いを解決しなければならない。取引出力がシールドされている場合、ウォレットは、どの暗号化データが自らのユーザーに属するのかをどう検出し、それを使うのに必要なwitnessをどう取得し、どのノートがnullifyされたかをどう把握し、indexerに金融活動の継続的なログを渡すことなくreorganizationに対応して最新状態を維持するのか。

Midnightの公式ローンチ発表によると、ネットワークは2026年3月29日に稼働を開始し、永続的な状態継続性を確立するとともに、本番運用を開始した。これにより、この問いの性質は変わる。シールド状態の検出は、もはや設計上の抽象論ではない。ウォレット、サービス事業者、ユーザーが敵対的な条件下で扱わなければならない、信頼性、プライバシー、インフラの問題である。

中心的な区別は見落とされやすい。暗号化はノートの内容を保護できる。しかし、そのノートを問い合わせるという行為まで自動的に保護するわけではない。ウォレットがviewing key、アドレス、直近の取引、特定のブロック範囲と相関するデータを繰り返し要求すれば、ウォレットもindexerも他ユーザーに属する平文を一切見ていないとしても、有用な行動記録が漏れる可能性がある。

台帳は公開のまま、状態をプライベートに保てる

MidnightのFAQによると、そのアーキテクチャではcommitment、nullifier、proofを公開台帳に置く一方、プライベート状態、鍵、proof入力はユーザーのデバイス上で暗号化されたまま保持する。実務上、チェーンが必要とするのは、取引が有効であり、従来は支出可能だったノートが二重に使われていないことを公開検証可能な形で示す証拠である。その証拠を送信者が構築するに至った詳細を、すべて公開する必要はない。

この分離は、二つの異なる役割を生む。

一つ目はコンセンサスである。ノードは取引を検証し、commitment treeを維持し、nullifierを記録し、ブロックについて合意する。二つ目はプライベート状態の復元である。ウォレットは、どのciphertextが関連するかを判定し、それらをローカルで復号または検査し、自らのノート集合を維持し、ノートをcommitment treeと関連付け、後の支出に必要なwitnessとproofを構築する必要がある。

プライバシーが静かに失われ得るのは、後者の役割である。

commitmentは誰にでも見え、公開commitment treeに挿入できる。nullifierも公開されており、バリデーターは同じノートを再び使おうとする試みを拒否できる。他方、ウォレットには、プライベートなノートデータと、関連するtree内の位置または経路が必要である。したがって公開チェーンは、ある状態遷移が正当であったことを証明できる一方で、暗号化された各出力が自分宛てかどうかの識別は各ユーザーに委ねられる。

これは、従来型の口座残高をダウンロードすることとは同じではない。アカウントベースのチェーンでは、ウォレットは多くの場合、アドレスの残高と取引一覧を問い合わせられる。シールドシステムでは、ウォレットは暗号化された出力のストリームを検査し、それぞれを復号または認識できるかを試した上で、支出可能状態に関する独自のローカルビューを組み立てる必要がある。

これが根本的なインフラ負担である。プライベート状態は単に保存されるのではない。見つけ出さなければならない。

indexerが知り得ること、リクエストが明かし得ること

Midnight公式Indexerリポジトリは、PostgreSQL、NATS、GraphQLアクセスなどのコンポーネントを利用する、chain indexer、indexer API、wallet indexer、SPO indexerで構成されるシステムを文書化している。この分離は重要である。本番アーキテクチャが一つの不透明なデータベースではないことを示しているからだ。これはチェーン活動を取り込み、index化された情報を保存・配信し、異なる種類のクライアントに提供するパイプラインである。

このリポジトリは、あらゆるデプロイメントを初期設定でプライベートにするものではない。ciphertextを保存するだけでそれを実現できるindexerアーキテクチャは存在しない。

indexerはウォレットのノート内容を読めない場合でも、次の事項を観測し得る。

• トラフィックがリレーされるなどの保護がない限り、ウォレットのリクエストのネットワークアドレスとタイミング。
• ウォレットが同期を開始または再開するブロック高。
• 同期リクエストの頻度とサイズ。
• クライアントが狭いデータ範囲について繰り返し問い合わせているかどうか。
• 更新に使用されるsubscriptionまたはAPIのパターン。
• エラー、リトライ、セッション時間などのサービスレベルのメタデータ。

FAQは、可視化される取引およびブロックのメタデータについても説明している。commitment、nullifier、取引の包含、ブロックの順序はコンセンサス上の役割を果たすため、正確にどの範囲が公開されるかは重要である。この公開記録はウォレットに有用なインフラを支え得るが、ユーザー、サービス運営者、第三者がタイミングやネットワーク活動を外部情報と結び付ければ、相関分析にも利用され得る。

これは機密データとプライベートなアクセスの違いである。ciphertextは直接読まれることから安全かもしれない。しかし、ウォレットがシステムと繰り返しやり取りすることで、活動中であること、資金を受け取ったおおよその時期、支出を試みた時期、特定のオンチェーンイベントに反応しているかどうかが明らかになる可能性は残る。

プライバシーリスクはproofの失敗ではない。周縁での観測である。

Nightridersは、取引内容が暗号化されている場合でも、タイミング、手数料、nullifier、ウォレットへの資金供給、選択的開示がリンク可能な行動を生み得ると論じた。これはプロトコル上の結論ではなく意見であるが、正しい監査対象を示している。すなわち、リクエスト、リトライ、エンドポイント、タイミングを含むproofの周辺システムである。

シールド状態を配信する四つの方法

プライベートなウォレット同期に単一の答えはない。帯域幅、レイテンシー、クライアントハードウェア、運用コスト、信頼の間にはトレードオフがある。有用な比較は、抽象的な「中央集権か分散型か」ではない。どの当事者がクエリパターンを見られるのか、誰がデータを差し止められるのか、ウォレットが何を独自に検証できるのかである。

中央集権型indexerは、モバイルウォレットに最も滑らかな体験を提供する。チェーンデータをスキャンし、関連構造を保持し、コンパクトなAPIを公開し、同期に必要なデータを返せる。その代償として、indexerは特権的な観測者となる。ノート内容を復号できなくても、クライアント行動の記録を構築できる可能性がある。

クライアント側スキャンは逆の道を取る。ウォレットは十分に広範なデータストリームをダウンロードし、関連性をローカルで判定する。これにより正確な関心対象を開示する必要性は最小化されるが、負担はデバイスに移る。完全なストリームは、帯域幅、ストレージ、CPU時間、バッテリー寿命の面で高コストになり得る。また、システムはクライアントのリソースを枯渇させるよう意図的に整形された悪意あるデータにも対処しなければならない。

コンパクトフィルターは中間案である。サーバーは、ウォレットがブロックに関連データが含まれる可能性を低コストで判断できるよう、ブロックごとの小さな要約を配信できる。その後、ウォレットは一致する可能性が高いものだけをダウンロードする。技術的な課題は、コンパクトフィルターがしばしば偽陽性を許容する点にある。これは関連性を曖昧にし、追加ダウンロードを発生させ得るが、プライバシーはフィルターの構築と、その後の取得パターンに依存する。フィルターは慎重に構築する必要もある。ウォレットが一致した少数のブロックだけを要求すれば、リクエストパターンそのものが識別要因になり得る。

Private Information Retrieval（PIR）は別の妥協案を提供する。indexerに特定の項目を直接要求する代わりに、ウォレットはどの項目を取得したかを隠すことを意図したプロトコルを使える。理論上、これは直接的なクエリ漏えいを抑える。実務上は、サーバーの計算負荷、クライアントの複雑性、リクエストのバッチ処理、トラフィックパターン、サービス拒否対策を巡る新たな問題を加える。PIRはデータベースクエリ内のindexを隠せる。しかし、それだけで特定のデバイスが特定の時点で活動中であることまで隠すことはできない。

複製データベースは、特にウォレットが回答を比較し、プロバイダーを切り替え、ブロック取得とwitness取得を分離する場合、一つのプロバイダーの権限を制限できる。しかし、複製だけで自動的にプライバシーが生まれるわけではない。同じ特徴的なクエリを三つのindexerに送れば、三つの運営者に同じ行動グラフを与えることになり得る。プライバシー上の利得は、取得プロトコル、運営者の独立性、クライアントが自らのリクエストパターンを一意に識別可能なものにしないで済むかどうかに依存する。

委任スキャンは、リソース制約のあるデバイスにとって魅力的になりがちである。ユーザーはサービスに対し、関連する出力を識別し、準備済みのウォレットビューを提供する権限を与える。これは実用的であり得るが、率直に呼ぶべきである。スキャンに関する信頼をデバイスから仲介者へ移す仕組みである。これが許容されるかは、どの鍵またはcapabilityを委任するのか、サービスが何を推測できるのか、ウォレットが完全性を検証できるのかに依存する。

可用性もプライバシーの一部

公式のMidnight Wallet SDKリポジトリによると、ウォレットはindexer clientを通じてシールド状態を同期する一方、Midnightノードおよびprover clientとは別途通信する。この分離には価値がある。クロスチェックの可能性を生むためである。indexerは利用しやすいチェーンデータのビューを提供し、ノードはブロック状態、root、その他のコンセンサス情報について独立した参照元を提供できる。

しかし、分離は実際に活用されなければ役に立たない。

Midnight Walletのissueに関する議論では、独立したfinality確認なしに、indexerが自己申告するtipを基準として同期完了を測定し得るという懸念が指摘された。この議論では、commitment-tree rootとブロック状態をノードに照合することが提案された。これはプロジェクト貢献者による批判的見解であり、すべてのデプロイメントがこのように失敗する証拠ではない。それでも、シールドウォレットに必要な基本的性質を示している。すなわち、「サービスが同期済みだと言うこと」と「自身の状態がネットワークにより独立して検証されたチェーン状態と一致すること」を区別できなければならない。

暗号化出力を差し止めるindexerは、それを盗めないかもしれない。しかし、より巧妙なことはできる。ユーザーに実際より残高が低いと信じ込ませる、ノートを支出可能として表示させない、支払いに対するウォレットの反応を遅らせる、といった行為である。したがって可用性と完全性は、プライバシーモデルに含めるべきである。同期障害の後、より情報開示の多いサービスへ緊急に切り替えざるを得ないユーザーは、完全なプライバシー保証を受けたとはいえない。

Wallet SDKのリリースノートは、indexerの稼働性、古いデータ、失われたsubscription、リトライ動作、シールドおよびDUSTウォレットに対する独立したindexerチェックが当初存在しなかったことに関する修正と制約を説明している。ここでも、提示されているのは批判的な視点だけである。反対の評価は提供されていないため、それを作り出す根拠はない。

reorganization、witness、サービス拒否

本番環境のシールド状態indexerには、高速なデータベース以上のものが必要である。

reorganizationポリシーが必要である。ブロックが置き換えられた場合、ウォレットはノートを取り消し、commitment tree上の位置を更新し、witness pathを破棄し、または安全な祖先ブロックから再スキャンする必要がある。indexerは、ウォレットがノードと照合できる形で、ブロックID、高さ、親子関係、finality状態を伝えるべきである。単調に増加する「最新の高さ」だけでは不十分である。

witnessポリシーが必要である。ウォレットがノートを認識しただけでは支出可能にはならない。ウォレットには、membershipを証明するための関連するcommitment-tree情報も必要である。indexer APIは、定義されたチェーン状態におけるwitnessの取得または再構築を可能にすべきであり、クライアントは未検証のpathを真実として受け入れるのではなく、rootを検証すべきである。

ストレージポリシーが必要である。すべての暗号化出力、commitment、nullifier、tree更新、履歴witnessデータを保持することは、増大圧力を生む。pruningはコストを下げ得るが、無計画なpruningは古いノートを復元上の問題に変える。システムは、ブロックから再生成できる履歴データ、保持されるデータ、新しいデバイスがウォレットを安全に復元するために必要なものを明示すべきである。

そして、サービス拒否ポリシーが必要である。攻撃者は、高コストなGraphQLクエリでindexerを過負荷にし、過剰なクライアントスキャンを強いるワークロードを生み出し、繰り返しの再同期を誘発し、subscription再接続の挙動を悪用する可能性がある。レート制限、ページネーション、認証済みサービス階層、応答サイズの上限は可用性に寄与し得るが、ヘビーユーザーや通常と異なるユーザーを識別しやすくする場合、いずれもプライバシーコストを生じさせる可能性がある。

実務的な設計原則は明快である。ウォレットはindexerを、チェーンに何が存在するかを最終的に決める権威ではなく、パフォーマンスサービスとして扱うべきである。

信頼できるシールド状態設計が証明すべきこと

Midnightにとっての問いは、シールドデータが公開台帳に存在できるかどうかではない。その二重状態モデルは、まさにその分離を目的に設計されている。問われるのは、周辺の取得アーキテクチャが、各ウォレットを少数のデータブローカーの予測可能なクライアントへ変えてしまうことなく、プライベート状態を利用可能にできるかどうかである。

ウォレットとindexerの監査では、次の点を問うべきである。

1. ウォレットは、同期済みのチェーンtip、commitment-tree root、reorganization状態を独立して検証できるか。
2. indexerによる完全性の宣言を受け入れるだけでなく、欠落データを検出できるか。
3. 通常の同期とsubscriptionにおいて、indexerは具体的にどのメタデータを受け取るか。
4. ユーザーは、クライアント側スキャン、複数プロバイダー、ローカルインフラ、プライバシー保護型取得を選択できるか。
5. 各選択肢の帯域幅、レイテンシー、バッテリーコストはどの程度か。
6. witnessデータ、履歴復元、pruningはどのように扱われるか。
7. どのサービス拒否対策が、通常と異なるユーザー行動を露出させるか。

暗号化は、観測者が何を読めるかを保護する。プライベートなアクセスは、観測者が何を推測できるかを左右する。Midnightの稼働ネットワークにより、この第二の問いは、ウォレットエンジニアリングがいま公に答えなければならない問題となった。