原文
Etherveil - An Ethereum Privacy Browser — pcaversaccio (2026-06-18)
重要: このドキュメントは進行中の作業であり、初期段階のアーキテクチャ提案を表しています。これは意図されたシステム境界と設計原則を定義しますが、最終的な実装やセキュリティ保証を特定するものではありません。Etherveilは仮称であることにご注意ください。この投稿の目的はコミュニティからのフィードバックを募ることですので、ぜひフィードバックをお寄せください！
ビジョン
Etherveilは、Tor BrowserのパッチセットをベースにしたFirefox/Geckoベースのブラウザで、Kohakuがネイティブウォレットエンジンとして組み込まれています。その核心的な前提はシンプルです。「プライバシーはユーザーが設定するものではなく、ランタイムの特性であるべき」というものです。
ほとんどのプライバシーツールは、この拡張機能をインストールし、このVPNを経由し、シールドアドレスを使用することを忘れないでください、といったようにユーザーに負担をかけます。Etherveilはこれを設計上の失敗と見なします。このブラウザは、ネットワーク（IPおよびトラフィックメタデータ）、実行（ブラウザのフィンガープリント表面）、およびオンチェーン（アドレス、トランザクションの送信元、残高）の3つのレイヤーでプライバシー・バイ・デフォルトを強制します。ユーザーはブラウザを開き、イーサリアムをサポートするサイトにアクセスし、割り当てられた匿名性クラスを超えて安定してリンク可能な識別可能なシグナルを生成することなく（そして、基盤となるメカニズムを理解する必要なく）トランザクションを実行できるべきです。Etherveilは、確率的プライバシーメカニズムを、すべての観測可能な実行表面に対する決定論的な制約強制に置き換えます。
システム不変条件
不変条件: すべての観測可能なブラウザAPIは、同じフィンガープリントプロファイルクラス内のユーザー間で共有される、有限の同等性クラスのセットに解決されなければならない。
簡単に言えば、同じプライバシープロファイルを使用しているすべてのユーザーは、ウェブサイトから見てまったく同じに見えます。これは、ブラウザがすべての観測可能な行動を少数の標準化されたパターンに強制するためです。
アーキテクチャ
┌────────────────────────────────────────────────────┐
│ Etherveilブラウザシェル (Firefox/Torフォーク) │
├───────────────────────────┬────────────────────────┤
│ 実行およびフィンガープリント │ Kohakuエンジン │
│ 正規化レイヤー │ (ウォレット + Tx) │
│ (Torブラウザベース) │ │
├───────────────────────────┴────────────────────────┤
│ ネットワークプライバシーおよび検証レイヤー │
│ Tor/オプションのMixnet、Heliosライトクライアント │
│ ERC-4337バンドラーリレー │
└────────────────────────────────────────────────────┘
フィンガープリント正規化レイヤー
Tor Browserはすでにほとんどの困難なフィンガープリンティング問題を解決しており、私たちはそれを拡張しているのであって、再発明しているわけではありません。主な追加機能は、私たちがフィンガープリントプロファイルと呼ぶものです。これは、経験的分布から導出された相関するブラウザシグナルに対する、制約を満たすタプルとして構築された、ブラウザの観測可能な要素に対する固定された事前計算済みの同等性クラスであり、ブラウジングコンテキストごとに割り当てられ、セッションの存続期間中は不変です。これにより、クロスフィールドの一貫性（例：タイムゾーン-ロケール-言語の一貫性）が保証され、独立した属性のなりすましが防止されます。
主要な設計上の決定は、これがユーザーごとの設定やランタイムのランダム化ではないということです。ランダム化は実際には逆効果です。キャンバスノイズシードがページロード間で変化する場合、その遷移自体がフィンガープリントになります。代わりに、各プロファイルは実世界の分布からオフラインで導出された一貫したスナップショットであり、ランタイムではサンプリングされず、それが属する匿名性セットのサイズを最大化するように選択されます。割り当てられたプロファイルの下でサイトが機能しなくなった場合、ブラウジングコンテキスト全体が別の互換性のあるクラスで再起動されます。セッション途中の変更はありません。
Gecko/SpiderMonkeyレベルで、決定論的なAPIインターセプトと書き換え（検出可能なコンテンツスクリプトではない）によって正規化される表面：
navigator.*: ユーザーエージェント (UA)、プラットフォーム、ハードウェア同時実行数、デバイスメモリIntl/Date: タイムゾーン、ロケール、言語ネゴシエーションヘッダー- Canvas/WebGL: プロファイルごとの決定論的な出力。ベンダーおよびレンダラー文字列はクラス分布に合わせられる。
screen.*、devicePixelRatio- WebRTC: ICE候補は抑制または標準化される
- 高エントロピーAPI（オーディオ、フォント、パフォーマンスタイミング）：プロファイルクラス全体で量子化される
すべての高エントロピーAPIは、量子化、統一、またはプロファイルに限定された同等性クラスにマッピングされます。
ストレージとインタラクションの隔離
ストレージ（IndexedDB、localStorage、クッキー、キャッシュ）はオリジンとプロファイルごとにパーティション化され、プロファイル間の漏洩はありません。ストレージに加えて、インタラクションシグナル（スクロールタイミング、ポインター移動、キーストロークの速さ）は、有界な確率モデル内で平滑化および量子化されます。目標は、ブラウザの使い心地を損なうことなく、生体認証による再識別を阻止するのに十分な行動エントロピーを削減することです。ユーザビリティとエントロピーのトレードオフ境界は、システムの主要な未解決の設計パラメータです。
Kohakuウォレットエンジン
ウォレットは拡張機能ではなく、ネイティブブラウザサブシステムです。ブラウザはdAppsに単一のトランザクションAPIを公開し、特定のトランザクションがプライベートに実行されているかパブリックに実行されているかを意図的に開示しません。その区別はエンジンの実装詳細であり、dAppsが知る必要はありません。
dApp -> ウォレットAPI -> Kohakuエンジン -> プライバシーリレー -> チェーン
| コンポーネント | 役割 |
|---|---|
| tornado-cash | デフォルトのシールドトランザクションレイヤー |
| プロバイダー | 統合RPC (Helios/外部ノード/ローカルクライアント) |
| pq-account | ポスト量子 (PQ) ERC-4337デフォルトアカウントタイプ |
すべての新しいアカウントは、デフォルトでpq-accountスマートアカウントです。ユーザーが明示的にパブリックフローを選択しない限り、トランザクションはTornado Cash（またはより一般的には、抽象的なzkシールドレイヤー）を経由します。UserOperationはTor経由のERC-4337バンドラーを介して送信されるため、ユーザーのIPはパブリックなメムプール (Mempool)内のトランザクションと関連付けられません。
ネットワークプライバシーレイヤー
ネットワークスタックはTor Browserから継承され、拡張されています。
- Tor (デフォルト): オリジンごとの回路分離。すべてのトラフィックとDNSは完全にルーティングされる。
- Mixnet (オプション): レイテンシを犠牲にして、タイミング相関攻撃に対するより強力なメタデータ耐性。これがオプトインであるべきかデフォルトであるべきかは保留。
- Heliosライトクライアント: 同期委員会証明によるローカルイーサリアム状態検証。集中型RPCプロバイダーへの依存を排除。ENS解決はHeliosのみを介して行われる。
- トラフィックシェーピング: タイミング相関を減らすための決定論的なレイテンシパディングとリクエストバッチ処理。
脅威モデル
このブラウザは以下のものから防御するように設計されています。
- ISPおよび出口ノードのトラフィック分析
- Canvas、WebGL、その他の高エントロピーAPIを介したクロスサイトフィンガープリンティング
- RPCエンドポイント監視（Infura/Alchemyなどへのアドレスクエリ）
- オンチェーンアドレスクラスタリングとトランザクショングラフ分析
- 行動生体認証による再識別（限定的な軽減策）
完全なネットワーク可視性を持つグローバルな受動的攻撃者、OSまたはハードウェアレベルのサイドチャネル、またはユーザーの運用セキュリティの失敗による攻撃を完全に解決するものではない（また、解決すると主張するものでもない）。
非目標
設計の一貫性を保つため、明確に範囲外となるいくつかの事項を挙げます。
- 拡張機能の互換性: WebExtension APIは、フィンガープリントモデルを損なうアイデンティティ表面を再導入する。
- ユーザー制御のフィンガープリント調整: 匿名性の保証は、個々のカスタマイズではなく、ユーザーが互いに区別できないことに依存する。
- オプトインまたは「ベストエフォート」なプライバシーモード: このモデルは、一様に強制される場合にのみ機能する。
- 実行モード（プライベート vs パブリック）をdAppsに公開すること。
保留中の設計上の質問
実装前に決定する必要があるが、まだ明確な正解がないいくつかの決定事項：
- プロファイルの永続性: 同じプロファイルをセッション間で特定のオリジンに割り当てるべきか、それともセッションごとにローテーションすべきか？オリジンごとの一貫性はユーザビリティに優れるが、ローテーションはリンク不可能性に優れる。
- Mixnetのデフォルト設定: ベースラインとしてTorのみを使用し、Mixnetはオプトインとするか、レイテンシに敏感なコンテキスト向けのエスケープハッチ付きでデフォルトオンとするか？
- インタラクションの強化: 行動エントロピー抑制とユーザビリティの許容可能なトレードオフはどこにあるか？
- ウェブ互換性: 厳格なフィンガープリントクラスでは、一部のサイトが機能しなくなる可能性がある。互換性のある高人口プロファイルクラスでサイトが正しくレンダリングされない場合の対応策は何か？
8件の投稿 - 3名の参加者