MidnightのDUST減衰、プライベート取引に新たなプライバシーのサイドチャネルを生む可能性

ネットワークは取引内容を隠せても、取引を取り巻くあらゆるシグナルまで隠せるわけではない。DUSTの生成、減衰、補充、手数料のスポンサー制度は、観測者が時間の経過に伴うウォレットの行動を把握する手段になり得る。

Midnightのプライバシーモデルは、取引内容の保護を目的に構築されている。ゼロ知識証明により、ネットワークは金額、残高、更新対象となる完全な状態などの機密情報を公開せずに、取引が有効であることを検証できる。

しかし、この保護が取引を取り巻くすべての情報に自動的に及ぶわけではない。

ユーザーは、ウォレットが稼働し始めた時期、資金補充の頻度、別の当事者が手数料を支払っているかどうか、休眠期間の長さなどをなお明らかにする可能性がある。Midnightでは、取引に必要なリソースがDUSTに結びついているため、こうしたシグナルが観測者にとってより有用になる可能性がある。DUSTはNIGHTの保有から生成されるネットワークリソースで、時間の経過とともに減衰する。

その結果、サイドチャネルが生じる可能性がある。観測者はプライベートな送金を読み取れなくても、その背後にあるウォレットの姿を描き出せるかもしれない。

これはMidnightのゼロ知識証明が破られているという主張ではない。取引のプライバシーと、行動のプライバシーの違いに関する問題である。Midnightのアプリケーションがテスト段階から本番環境へ移行する中、開発者はDUSTの補充や手数料の動きが、識別可能な利用パターンを生み出すかどうかを検証する必要がある。

この問題が最も重要になるのは、支払い自体が暗号学的に保護されていても、メタデータによって個人を特定できるアプリケーションである。

DUSTが変えるもの

DUSTは、Midnight上で計算やその他のネットワークリソースの支払いに使われるよう設計されている。ユーザーに操作のたびに従来型の手数料トークンを使わせるのではなく、システムはリソースの利用可能性をNIGHTの保有量に結び付ける。

このモデルは2つの機能を分けている。NIGHTはユーザーが保有する資産であり、DUSTはネットワーク上で活動するために使われるリソースである。NIGHTを保有またはロックするとDUSTを生成でき、DUSTは徐々に減衰する。この設計は、NIGHT保有者にとってネットワークへのアクセスを予測可能にすると同時に、取引のたびに別の手数料資産を取得する必要性を減らすことを意図している。

これはアプリケーションにとって有用な抽象化となる。ウォレットはNIGHTを保有し、そこから得られるDUSTでプライベートな操作を支えられる。アプリケーションは、取引設計におけるリソース支払いの扱い次第で、ユーザーの活動をスポンサーすることもできる。

しかし同じ仕組みが、ウォレットの稼働プロファイルに時間という要素を持ち込む。

大量のNIGHTを保有するウォレットは、少量しか保有しないウォレットとは異なるペースでDUSTを補充する可能性がある。頻繁に取引するウォレットは、月に1度だけ使われるウォレットとは異なるペースでリソースを消費する可能性がある。ウォレットが非アクティブな間にDUSTが減衰すれば、次の取引で目に見える補充、別のスポンサー、または取引へのリソースの付加方法の変更が必要になるかもしれない。

こうした違いから、保護対象のプライベートな状態が明らかになるとは限らない。それでも観測者がウォレットを識別する手がかりにはなり得る。

重要なのは、1回のDUSTの動きでユーザーを特定できるかどうかではない。繰り返される動きが安定したパターンを生み出すかどうかである。

メタデータの問題

プライバシーシステムは、取引の内部に含まれる情報に焦点を当てることが多い。これには送信者、受信者、金額、資産の種類、アプリケーションの状態などが含まれる。ゼロ知識技術によって、これらの項目の一部または全部を公開観測者から隠せる。

メタデータは、保護された内容の外側に存在する。

観測者は、取引がブロードキャストされた時刻、承認された時刻、どの公開アドレスまたはアカウントがリソースを供給したか、DUSTの補充が必要だったか、別のアカウントが手数料をスポンサーしたかどうかを確認できる可能性がある。ネットワーク上の通信は、チェーン自体が取引のプライベートな項目を開示していなくても、アプリケーションのセッションと取引送信とのつながりを明らかにする可能性がある。

個々のシグナルは弱い。しかし、組み合わせれば個人の特定につながる可能性がある。

給与支払いアプリケーションを考えてみよう。従業員は毎月おおむね同じ時期にプライベートな支払いを受け取る。支払い金額や受取人は隠されていても、周辺の活動は一様ではないかもしれない。あるウォレットは給与を受け取るたびにDUSTの補充が必要になる。別のウォレットは、保有するNIGHTから継続的にリソースを生成できるかもしれない。3つ目のウォレットは、給与システムが一括で支払いを送った直後に、取引を資金提供するスポンサーアカウントを通じて操作する可能性がある。

こうした動きを数カ月にわたって観測すれば、観測者はウォレットを行動パターンごとに分類できる。さらに、企業の給与支払日、従業員の入社や退社、特定のユーザーがアプリケーションにアクセスした時期を把握していれば、そのグループに名前を付けやすくなる。

観測者は非公開の給与額を復元する必要はない。ウォレットと従業員を結び付けるだけでも、深刻なプライバシー問題になり得る。

医療アプリケーションも同様のリスクに直面する。患者はプライベートなアプリケーションを使って、資格を証明したり、給付を受け取ったり、支払いを承認したりする可能性がある。医療記録と取引金額は隠されたままでも、診療所の営業時間と結び付いた繰り返しの活動パターンから、ウォレットがサービスを利用していることが明らかになる可能性がある。

ガバナンスでは、プライベートな投票や委任システムが投票内容を隠しながら、参加パターンを露呈させる可能性がある。機関投資家などのユーザーは取引内容を保護できても、機密性の高い交渉中に財務ウォレットが稼働したことを明らかにしてしまう可能性がある。

したがって、プライバシーには2つの問いがある。誰から見てプライベートなのか、どの側面がプライベートなのかである。Midnightは、取引内容については前者の問いに対応できる。開発者は、タイミングやリソースの動きがプライバシーの境界に含まれるかどうかをなお決める必要がある。

DUSTの減衰が指紋になり得る仕組み

減衰そのものがプライバシー上の弱点というわけではない。減衰はリソース設計の一部である。減衰スケジュールが予測可能なユーザー行動と組み合わさったときに、プライバシーリスクが生じる。

毎日使われるウォレットを考えると、そのDUST残高と補充の必要性は一定のパターンに従う可能性がある。週に1度使われるウォレットは別のパターンになる。長期間沈黙していた後に稼働するウォレットは、次の操作に追加のDUSTが必要になる場合、さらに別のパターンを示す可能性がある。

分析者は次の情報を記録できる。

• 取引間の時間
• DUST補充の金額または供給元
• 補充がアプリケーション呼び出しの前に行われたか後に行われたか
• リソースを供給する公開アカウント
• ウォレットが非アクティブである期間
• 複数のウォレットが同じスポンサーからリソースを受け取っているかどうか
• ユーザーセッションから取引承認までの時間

分析者は正確なDUST残高を知らなくてもよい。動きの連続性そのものが指紋になる可能性がある。

これは、他のプライバシーシステムにおけるトラフィック分析に似ている。暗号化はメッセージの内容を隠せても、パケットのサイズ、タイミング、頻度は見えるままになる。ネットワーク観測者は、データを復号せずにこうしたパターンから活動内容を推測できる。

DUSTはこの問題にアプリケーションと経済の層を加える。リソースの消費と補充は単なるネットワーク上の痕跡ではない。ユーザーがどれだけ取引するか、どのくらいの頻度で戻ってくるか、どの主体がアクセス費用を支払うかを反映する可能性がある。

アプリケーションが標準化されたワークフローを使うと、リスクは高まる。同じ業務プロセスの同じ段階で同じ呼び出し手順を常に実行するウォレットは、ランダム化または共有されたリソース管理を使うウォレットより分類しやすい。

スポンサーの顧客層が狭い場合もリスクは高まる。1社が少人数のユーザーにDUSTを資金提供している場合、スポンサーの活動が目に見えるラベルになる可能性がある。スポンサー自身がどのプライベートな取引が誰に属するかを知らなくても、外部の観測者がスポンサーの活動を他の公開イベントと相関させられる可能性がある。

スポンサー付き取引は便利だが、見えなくなるわけではない

手数料のスポンサー制度は使いやすさを高められる。プライベートなアプリケーションを使う前に、ほとんどの人はNIGHTを取得したりDUSTを管理したりしたいとは思わない。スポンサーが必要なリソースを支払えば、アプリケーションは従来型のウェブサービスに近い感覚になる。

スポンサー制度は、ユーザーが自分の活動に公に資金を供給する必要をなくすことで、プライバシーを改善する可能性もある。共通のスポンサーを使えば、多くのユーザーを同じように見せられる。特に、リクエストをまとめて処理し、一貫した送信手順を使う場合に有効である。

ただし、その結果は自動的に得られるわけではない。

スポンサーが各ユーザーに個別に資金を提供すれば、スポンサーと受取ウォレットの明確な関係が生まれる可能性がある。顧客ごとに異なるリソースアカウントを使えば、アカウント構造自体が追跡手段になる可能性がある。ユーザーのログイン直後に取引へ資金を提供すれば、タイミングによってオフチェーンの活動とオンチェーンの活動が結び付く可能性がある。

スポンサーは、機密性の高い運用データにアクセスできる信頼された当事者にもなり得る。プライベートな取引状態を読み取れなくても、どのユーザーがリソースを要求したか、いつ要求したか、どのアプリケーション機能が呼び出されたかを知る可能性がある。

開発者は、次の3つの問いを分けて考える必要がある。

1. スポンサー制度はユーザーによる手数料の支払いを隠すか。
2. ユーザーとスポンサーの関係を隠すか。
3. 外部の観測者が繰り返される取引を結び付けるのを防げるか。

設計によっては、1つ目の問いには「はい」と答えられても、残り2つには「いいえ」となる可能性がある。

プール化は、リンク可能性を下げられる。ユーザーごとに専用の資金供給経路を割り当てる代わりに、アプリケーションは共有スポンサーインフラを使い、取引をまとめて送信できる。タイミングを標準化し、ユーザーが操作を開始した正確な瞬間への依存度を下げることもできる。

こうした対策にはコストがある。バッチ処理は遅延を増やす可能性がある。パディングやランダムなタイミングは、アプリケーションの応答性を低下させる可能性がある。共有プールには慎重な会計処理が必要で、不正利用の防止を複雑にする可能性もある。どの選択が適切かは、アプリケーションが利便性、金融上の機密性、アイデンティティのいずれを守ろうとしているかによって変わる。

開発者が測定すべきもの

最初のステップは、DUSTの動きを実装上の細部ではなく、脅威モデルにおけるデータとして扱うことである。

開発者は、公開されるリソースの動きから観測者がユーザーを識別できるかどうかをテストすべきである。プライベートな取引内容にアクセスする必要はない。NIGHTの保有量、活動頻度、非アクティブ期間が異なるシミュレーションウォレットを使えば、有用な実験ができる。

テストでは次の要素を変えるべきである。

• ウォレットの規模とDUST生成率
• 取引頻度
• 非アクティブ期間の長さ
• 必要なリソースが異なるアプリケーション呼び出し
• 直接の資金提供とスポンサー制度の比較
• 個別の補充とプール化された補充の比較
• 即時送信と遅延送信またはバッチ送信の比較

結果は分類問題として分析すべきである。観測者は、2つの取引が同じウォレットから行われたと判断できるか。特定の顧客グループに属するウォレットだと識別できるか。ウォレットがアプリケーションの利用を停止したと推測できるか。

取引内容を隠しながら、こうした問いに確実に答えられるシステムには、追加の保護が必要になる可能性がある。

1つの方法は、リソース管理をユーザーの主要なアイデンティティから切り離すことである。ウォレットは、DUSTの補充を処理するスポンサーまたは仲介者を介してやり取りできる。これにより、ユーザーと公開された資金供給活動の直接的なつながりは弱まるが、信頼と運用上の責任は仲介者へ移る。

別の方法は、補充を予測しにくくすることである。アプリケーションは各取引の直前に補充する代わりに、共有されたリソース残高を維持し、不規則な間隔で補充できる。また、複数の取引を共通の経路で送信し、個々の利用を切り分けにくくすることもできる。

開発者はランダム化に注意すべきである。基盤となるウォレットやスポンサーが固有であれば、タイミングをランダム化しても役に立たない。また、ランダム化の方法が適切に設計されていなければ、新たなパターンを生む可能性もある。プライバシーエンジニアリングは、各ユーザーに少しずつ異なる偽装を与えるよりも、多くのユーザーが同じ観測可能な行動を共有する場合に最も有効である。

アプリケーションは、公開アカウント間の関係も最小限にすべきである。1つの組織だけが使うスポンサーアドレスは、永続的な識別子として機能する可能性がある。共有インフラ、運用アカウントのローテーション、会計記録と公開された資金供給経路の明確な分離は、露出を減らせる可能性がある。ただし、これらの選択肢のいずれも完全な解決策ではない。

最後に、チームは何をプライベートだと考えているのかを文書化すべきである。「プライベートな取引」という表現は広すぎて、実装の指針にはなりにくい。より強固な仕様では、チェーンの観測者から金額は隠される一方、取引のタイミングとスポンサーの活動は見える、と明記するだろう。タイミングが機密であれば、アプリケーションにはタイミングに直接対応する設計が必要になる。

ウォレットとインフラの役割

プライバシーの結果は、スマートコントラクトだけで決まるわけではない。ウォレットソフトウェア、RPCプロバイダー、リレイヤー、アプリケーションサーバーはいずれもメタデータを追加する可能性がある。

ウォレットは、ネットワークへのリクエストを通じてどのアプリケーションが使われているかを露呈させる可能性がある。RPCプロバイダーは、送信前のユーザーのIPアドレス、リクエストのタイミング、取引ペイロードを確認できる可能性がある。リレイヤーは、プライベートなクライアントと公開取引とのつながりを把握する可能性がある。アプリケーションサーバーは、DUSTで資金提供された呼び出しを引き起こしたユーザーセッションを記録できる可能性がある。

こうした当事者に悪意がなくても、公開チェーンデータと組み合わせれば、そのログが相関分析の情報源になる可能性がある。

したがって、プライバシー重視のMidnightアプリケーションは、ユーザーの操作から承認までの経路全体を見直すべきである。誰がリクエストを観測できるのか、誰が資金を提供できるのか、誰が遅延させられるのか、誰がアカウントと結び付けられるのかを問う必要がある。運用ログをどれだけの期間保存するかも定めるべきである。

ユーザーはウォレットのインターフェースだけで、こうした問題のすべてを解決することはできない。アプリケーションが固有の資金供給パターンを露呈させる場合、ユーザーにはそれを隠す現実的な手段がない可能性がある。必要なリソース操作がアイデンティティの目印にならないようにする責任は、開発者とインフラ運営者にある。

暗号学の失敗ではなく、設計上の問題

MidnightのDUSTモデルは、すべてのユーザーに別の手数料トークンの管理を強いることなく、ネットワークリソースを利用可能にする実用的な方法となる可能性がある。これは消費者向けアプリケーション、企業のワークフロー、プライベートなスマートコントラクトにとって有用である。

同時に、チェーン上には観測可能なリソース経済が存在することになる。DUSTの生成、消費、減衰は、時間の経過に伴うウォレットの状態や利用状況を反映する可能性がある。こうした要素と個人の行動との関係が予測しやすいほど、そこから得られるシグナルの価値は高まる可能性がある。

これはゼロ知識証明を弱めるものではない。証明が金額を正しく隠していても、取引のタイミングは見える可能性がある。チェーンの観測者がメッセージを読めないようにしながら、繰り返されるリソース補充によってユーザーが戻ってきた時期が明らかになる可能性もある。

この区別は重要である。対応策が変わるからだ。暗号技術が失敗したと主張するのではなく、暗号技術がカバーしない情報を前提にアプリケーションを設計する必要がある。

Midnightの開発者にとっては、DUSTの補充と減衰を潜在的なメタデータとして扱うことを意味する。スポンサー付き取引は、利便性だけでなくリンク可能性の観点から評価すべきである。ウォレットとリレイヤーの動きもプライバシーのテストに含める必要がある。給与、医療、ガバナンス、機関向けのユーザーにサービスを提供するアプリケーションは、入念な観測者がチェーンデータと外部情報を組み合わせることを前提にすべきである。

プライベートな取引は、必ずしもプライベートなやり取りではない。Midnightは前者を可能にできる。後者を構築するには、タイミング、資金供給、プール化、運用ログについて意図的な選択が必要になる。

DUSTは残高としては見えないまま、パターンとして見えるようになる可能性がある。そのパターンは、開発者が今測定すべきサイドチャネルである。