Midnightのプライバシー検証、ゼロ知識証明からメタデータへ

次のプライバシー問題は可視化された挙動

Midnightのメインネットによって、プライバシーをめぐる問いは、取引が有効なゼロ知識証明を生成できるかどうかから、有効な取引とその周辺活動を見た観測者が何を推測できるかへと変わる。

ゼロ知識証明により、証明者は基礎となる秘密データを明らかにせず、ある命題が真であることを証明できる。Midnightのアプリケーションでは、これによりプライベートな状態や機密性の高い取引ロジックを実現できる。ユーザーに権限があること、残高が十分であること、状態遷移がコントラクトのルールに従っていることを証明しながら、特定の値を非公開にできる。

この性質は重要だが、観測可能な挙動をすべて隠すこととは異なる。公開台帳にはなお、活動の表面が存在する。分析者は、取引が到着する時刻、アドレスが動作する頻度、呼び出すコントラクト、消費するDUSTの量、nullifierが現れる時点、ウォレットへの資金供給方法を調べられる。nullifierは、プライベートなノートや請求権が二重に使用されるのを防ぐために公開される値である。基礎となるノートを明らかにする必要はないが、その出現は認識可能な活動パターンの一部となり得る。

ここで区別されるのは、内容のプライバシーとメタデータのプライバシーである。内容のプライバシーは、操作の内部にある値やペイロードを保護する。メタデータのプライバシーは、操作自体に関する事実、つまりタイミング、サイズ、頻度、取引相手、他のイベントとの関係などに関わる。

証明を破らなくてもパターンからユーザーを特定できる

プライベートな給与支払いアプリケーションを考えてみよう。企業が毎月同じ時刻に機密性の高い支払いを配布するとする。支払い額と受取人の残高は隠されたままでも、繰り返される取引スケジュールから雇用主の給与支払いサイクルが特定される可能性がある。受取人が支払い直後にその資金を使ったり統合したりすれば、その一連の動きによって個々のウォレットを分類しやすくなる可能性もある。

本人確認システムも同様の問題に直面する。認証情報の確認によって、ユーザーが一定の年齢以上であるといった条件を満たしていることだけを明らかにできる。これは選択的開示であり、認証情報全体ではなく、必要な事実だけをユーザーが開示することを意味する。しかし、同じアプリケーションに対する確認を繰り返したり、特徴的な時刻に開示したりすると、認証情報の内容が非公開のままでもプロファイルが作られる可能性がある。

投票アプリケーションも別の境界事例を生む。投票の秘密は、投票内容を隠すだけでは守れない。登録、投票の提出、取り消しのイベントが、認識可能な少数のパターンに従っている場合、観測者は参加の事実を推測したり、行動を特定の集団と結び付けたりできる可能性がある。企業記録も、コントラクト呼び出しのパターン、決済スケジュール、更新のタイミングを通じて、同様の形で漏れる可能性がある。

こうした推測はいずれも、Midnightの証明システムを破る必要がない。観測者が必要とするのは、十分に長い履歴と、そのパターンを個人、企業、機関に結び付けるのに十分な外部情報だけかもしれない。

DUSTとウォレットの挙動も脅威モデルの一部

DUSTの消費も有用なシグナルとなる可能性がある。手数料やリソースコストから、コントラクトが処理した秘密の値が必ずしも明らかになるわけではないが、繰り返されるコストによってアプリケーションの種類やユーザーのワークフローを識別できる可能性がある。ウォレットが行動のたびに1件の取引を送信する場合、そのコストとタイミングが安定した指紋を形成する可能性がある。複数の行動をまとめて処理すれば、異なるパターンになるかもしれないが、それでも識別可能な場合がある。

資金供給も、結び付きを生む別の要因である。既知の公開アドレスから運用資金を受け取るプライベートウォレットは、そのアドレスの身元を引き継ぐ可能性がある。資金の統合、アカウント復旧、アプリケーション用ウォレット間の送金によって、プライバシー設計が分離を意図していた活動がつながる場合もある。

Compactのツールチェーンは、アプリケーションのどの状態を非公開にし、コントラクトが何を開示するかを定義できるが、ユーザーの挙動によって生じるすべてのシグナルを自動的に消去することはできない。したがって開発者には、アプリケーションレベルの脅威モデルが必要となる。そこでは、どの観測者がどの程度の能力を持つと想定するのか、どのような外部データを保有している可能性があるのか、どの推測をプライバシー侵害とみなすのかを明示すべきである。

プライバシー指針は証明だけでなくトラフィックも対象に

実際の対策は他のプライバシーシステムでも知られているものだが、Midnightのアプリケーションとウォレットに組み込む必要がある。トラフィック整形は、遅延を加えたり、予測しにくいスケジュールで活動を送信したりすることで、タイミング情報の有用性を下げられる。バッチ処理によって複数の行動を1つの操作に見せることもできるが、独自の特徴的なパターンを生む可能性がある。ウォレットはアドレスの不必要な再利用を避け、自動的な開示を制限できる。

分離が重要な場合、アプリケーションは身元とワークフローも分けるべきである。給与支払い用ウォレットが、公開ガバナンス活動に使うウォレットと自動的に同一になってはならない。選択的開示のインターフェースでは、どの事実を誰に開示するのか、その開示が過去のイベントと結び付けられる可能性があるかをユーザーに示すべきである。

こうした対策にはトレードオフが伴う。遅延は使い勝手を損なう可能性がある。バッチ処理は復旧や会計処理を複雑にする可能性がある。活動頻度を高めれば、追加のDUSTを消費する可能性がある。アプリケーションが固有で即時かつ公開された行動を要求する場合、ウォレットはメタデータのプライバシーを保証できない。

Midnightのプライバシーに関する主張は、こうした選択が実際に展開されたシステムでどのように処理されるかに、ますます左右されることになる。ゼロ知識証明は、非公開の計算が有効であることを証明できる。しかし、それだけで、その計算を運ぶトラフィックの形まで隠せるわけではない。開発者、ウォレット、機関にとって、次のセキュリティー審査では2つの図を描くべきである。1つは証明と状態のパイプライン、もう1つはその周囲で観測可能なすべてのイベントを示す図である。