Midnightの連合型mainnet、プルーフサービス設計が次の本番ボトルネックに

これは、proverをアプリケーションのクリティカルパスの一部にする。

有効なproofは、基礎となる非公開入力を公開せずに、ユーザーが状態遷移を実行する権限を有していたことを立証できる。しかし、ユーザーがproof生成能力を利用できること、関連するwitnessが最新であること、リクエストがノードに到達すること、あるいはウォレットが後の支出に十分な状態を保持することまでは立証しない。これらは別個のエンジニアリング上の課題であり、それらを混同するプライベートアプリケーションは、いずれユーザーをローディング表示の前に取り残すことになる。

Midnightの設計では、コントラクト状態をパブリックなオンチェーン状態とローカルなプライベート状態に分け、ユーザーはトランザクションを送信する前に状態変更を証明する。The BlockがMidnightと協力して2025年に発表したリサーチ特集では、ブラウザーのインターフェースと拡張機能がproofサーバーと通信し、インデクサーおよびネットワーク更新用の投票権を持たないノードが併設される構成が説明された。本番運用で重要なのは、proofサーバーが存在するかどうかではない。誰が運用し、何を見られ、障害時にアプリケーションが何をするかである。

意図からファイナリティまでのトランザクション経路

プライベート送金または規制対象のクレデンシャル確認を考えてみよう。ユーザーはウォレットで確認を押す。そこから始まるにすぎない。

まず、ウォレットまたはアプリケーションが意図を構築する。この金額を送金する、このコントラクト関数を呼び出す、このクレデンシャルを提示する、あるいはこのプライベート記録を更新するといった内容である。コントラクトのバージョン、想定されるパブリック状態、手数料リソース、トランザクションの有効期限を特定する。

次に、witnessを収集する。witnessとは、回路を満たすために必要な非公開の素材である。秘密鍵、ノートまたはローカル記録、認証パス、暗号化された状態、非公開入力、さらに支出または更新対象の状態がなお有効であることを示すために必要となりうる直近のチェーンデータなどが含まれる。正確な内容は回路固有である。要点はより単純だ。witnessはトランザクションそのものより機密性が高い場合が多い。

第3に、proverが意図、パブリック入力、witnessに対して回路を実行する。すべての制約が満たされれば、proofと、nullifier、コミットメント、状態ルートへの参照、開示されたコンプライアンス結果など、ネットワークが確認すべきパブリック出力を生成する。

第4に、ウォレットはそれらの出力をトランザクションにまとめ、プロトコルが求める認可に署名する。トランザクションは送信エンドポイントまたはノードに送られる。バリデーターは回路の検証鍵とパブリック入力に照らしてproofを検証し、コンセンサスおよび状態遷移ルールも満たしていれば、トランザクションを取り込む。

PRIVATE WITNESSkeys, notes, paths and private inputs

witness and private inputs

PROVERruns the circuit locally or as a service

proof and public outputs

PROOF PACKAGEproof plus public outputs

proof and disclosed outputs

SIGNED TRANSACTIONpackages the outputs for submission

signed transaction

VALIDATOR / VERIFIERchecks proof, inputs and state rules

重要な違いは、proof検証はネットワーク機能として実行できるほど軽量である一方、proof生成はデバイスまたはサービスの機能になりうる点だ。バリデーターにwitnessは不要である。必要なのはproof、パブリック入力、正しい検証鍵だけだ。高コストの作業を担うのはproverであり、そのトポロジー次第ではユーザーの最も私的なデータを扱う可能性がある。

有効性は可用性ではない

ゼロ知識が答えるのは限定的な問いである。すなわち、誰かがwitnessを明かさずに、この遷移が回路に従うことを示したか、である。

ゼロ知識は、次の4つの運用上の問いには答えない。

1. **可用性：**ユーザーはいまproverに到達できるか。
2. **レイテンシー：**ユーザーがフローを離脱する、またはトランザクションが期限切れになる前にproof生成は完了するか。
3. **鮮度：**witnessは、なおチェーンと一致する状態に基づいて構築されているか。
4. **メタデータプライバシー：**このネットワークアドレスから、この時点に、このユーザーがこの回路を要求したことを誰が知るのか。

proofサービスは完全に誠実で高い可用性を持っていても、タイミング、IPアドレス、回路識別子、proofの所要時間、リクエストサイズ、クライアントのバージョン、再試行の挙動を収集しうる。プライベートな給与計算アプリ、医療クレデンシャルのワークフロー、ユーザーのために行動するAIエージェントにとって、このパターンはサービスが秘密鍵を一切読まなくても意味を持ちうる。

CoinDeskによる2025年のMidnight概要では、その後の分散化段階に先立つ2026年初頭の連合型フェーズについて、IOGと外部のエンタープライズ運営者が混在して運用する安定した本番環境と説明された。連合型バリデーターは、チェーンの信頼性ある立ち上げに役立つ可能性がある。しかし、proof生成経路を自動的に分散化するものではない。アプリケーションは依然として単一のproof生成事業者を導入でき、それによりコンセンサスの外部にプライベートデータと稼働時間の依存関係を生み出すことになる。

3つのproof生成トポロジー

普遍的に正しいモデルはない。選択は、witnessの機密性、想定トランザクション量、デバイスの種類、運用上の依存への許容度によって決まる。

ブラウザーローカルproof生成

ブラウザーローカルproof生成は、最も明確なプライバシー境界を提供する。witnessはウォレットまたはブラウザー内にとどまる。アプリは回路アーティファクトをダウンロードし、ローカル状態を導出し、proofを作成して、1つ以上のノード経由で送信できる。

これは、アプリケーションがユーザーのプライベートな金融、本人確認、エージェントのデータを閲覧できないと約束する場合に優れた設計である。耐障害性も向上する。商用proverの障害が発生しても、対応ウォレットと到達可能なRPCエンドポイントを持つユーザーは停止しない。

コストは現実のものだ。proof生成はメモリー、CPU、バッテリー、時間を消費しうる。大規模なproof生成鍵は安全に配布し、正確にバージョン管理しなければならない。モバイルブラウザーやハードウェア制約のあるデバイスは、暗号学的保証を使えないソフトウェアに変えかねない。開発者は、開発用ノートPCではなく、サポート対象で最も性能の低いデバイスでproof時間の中央値とテール値をベンチマークすべきである。

アプリケーション運用proof生成

ホスト型proverは、最も滑らかな消費者体験を実現する。アプリケーションはアーティファクトをキャッシュし、最適化されたハードウェアを使い、ワーカーをオートスケールし、障害を集中的に観測できる。アーキテクチャーが許せば、ワークロードをバッチ処理することも可能だ。

しかし、「witnessは通信中に暗号化されている」はプライバシー上の問いへの答えではない。問うべきなのは、サービスがproof生成のために復号するのか、または十分な非公開素材を受け取るのかである。そうであれば、そのサービスは機密性境界の内側にある。明示的な保持ルール、アクセス制御、メモリー処理、ログのマスキング、インシデント対応、監査証跡が必要になる。

より防御可能な中間案は、暗号化または分割されたwitness設計に基づくリモートproof生成であり、サービスが直接支出可能な秘密情報より少ない情報を受け取る方式だ。これは露出を減らすが、メタデータ漏えいを消し去るものでも、サービス実装を信頼する必要性をなくすものでもない。暗号技術は影響範囲を縮小すべきであり、「信頼不要」をうたうマーケティング上の同義語になってはならない。

外部委託のproverインフラ

専業prover事業者は、大規模アプリケーションにとって合理的な選択となりうる。専用ハードウェアを稼働させ、アーティファクトのキャッシュを管理し、地域をまたいで処理能力を提供できる場合がある。欠点は明白である。アプリケーションは事業者の障害、レート制限、テレメトリーポリシー、アップグレード頻度、商業上のリスクを引き継ぐ。

プライベートなワークフローでは、少なくとも独立して運用される2社の事業者を利用するか、権限の高いユーザー向けにローカルのフォールバックを維持すべきである。同じクラウドアカウント上の第2エンドポイントは、見せかけの冗長性にすぎない。

プロダクト上の判断を要する5つの障害

**古いローカルwitness。**proof生成中に別のトランザクションがノートを消費したり、コントラクトルートを変更したり、前提を無効化したりする可能性がある。古い状態は例外的エラーではなく、通常の再試行経路として扱うべきである。状態を再取得し、witnessを再構築し、proofを再生成する。古いproofを無条件に再送信してはならない。

**リクエストのタイミングを知るprover。**witnessがウォレットの外に出なくても、リモートエンドポイントは特定の回路がいつ呼び出されたかを知りうる。ローカルproof生成後の直接送信、適切な場合のリレー、粒度を粗くしたテレメトリー、短期保持、実用的な範囲でのリクエストパディング、proverログへのユーザー識別子非記録によって、これを最小化する。

**proof作成後、ブロードキャスト前のクラッシュ。**proofは有効でも、トランザクションがネットワークに到達したかどうかの記録をウォレットが持たない可能性がある。ブロードキャスト前に、暗号化されたトランザクションジャーナルを永続化する。そこには署名済みトランザクション、proofアーティファクトまたは再現可能なproof生成入力、送信時刻、冪等性識別子、現在の状態を含めるべきである。再起動後は、代替トランザクションを生成する前に取り込み状況を照会する。

**アップグレード後の非互換アーティファクト。**proofは回路および検証鍵に結び付く。ネットワークまたはコントラクトがアップグレードされると、キャッシュされたproof生成鍵はバリデーターが拒否するproofを生成しうる。すべての回路アーティファクトを不変ハッシュでバージョン管理し、proof生成前に互換性チェックを必須とし、それらを使う全トランザクションの有効期限ウィンドウが過ぎるまで旧アーティファクトを保持する。

**支出可能な状態を伴わないウォレット復元。**シードフレーズで鍵は復元できても、効率的な支出に必要なすべてのローカル記録、暗号化ノート、witnessキャッシュまで必ずしも復元できるわけではない。バックアップが何を復元するかを明確に定義する必要がある。鍵のみか、鍵と暗号化されたプライベート状態か、信頼できるソースから再構築する復元可能な履歴かである。ウォレットを復元可能と呼ぶ前に、新しいデバイスで復元をテストする。

アーキテクチャーを要件に落とし込む

有用な設計レビューは、テスト可能な回答を導くべきである。

• witness素材の各分類は、平文および保存時にどこに存在するか。
• プライマリーproverが利用不能でも、ユーザーはproofを生成して送信できるか。
• 95パーセンタイルで許容されるproofレイテンシーの上限はどの程度か。
• ウォレット、アプリケーション、prover、RPC事業者はそれぞれどのイベントを記録するか。
• 各運営者はどのメタデータを相関付けられるか。
• クライアントは回路アーティファクトをどのように発見、検証、ロールバックするか。
• ユーザーは中断されたトランザクションが取り込まれたかを確認できるか。
• 支出能力を復元するために必要となる正確なデータは何か。

推奨事項は明快である。プライバシーが製品そのものであり、ハードウェアが許す場合は、ブラウザーローカルproof生成を標準とする。ユーザー体験のために必要であればアプリケーション運用サービスを使うが、プライベートデータを扱いうるセキュリティクリティカルなシステムとして扱う。外部委託proof生成は、定義されたフェイルオーバー経路、メタデータポリシー、撤退計画がある場合に限って利用する。

Midnightはwitnessを見ずに正しいproofを検証できる。これが暗号学的な成果である。だがアプリケーションには依然として、proof生成を利用可能で、復旧可能で、運営者からもプライベートなものにする責務がある。