重要提示：本文檔尚處於開發階段，僅代表早期架構方案。它定義了預期的系統邊界和設計原則，但並未明確最終實現方案或安全保證。請注意， Etherveil僅為暫定名稱。本文旨在收集社群回饋，歡迎分享您的意見！
想像
Etherveil 是一款基於Firefox / Gecko核心的瀏覽器，它採用了Tor 瀏覽器的補丁集，並嵌入了Kohaku作為原生錢包引擎。其核心概念很簡單：隱私應該是執行時期環境的屬性，而不是使用者需要配置的。
大多數隱私工具都會負擔轉嫁給用戶，例如安裝這個擴充功能、透過這個 VPN 路由、記住使用屏蔽位址等等。 Etherveil 將此視為設計缺陷。此瀏覽器在三個層面強制執行預設隱私保護：網路層（IP 和流量元資料）、執行層（瀏覽器指紋識別）和鏈上層（位址、交易來源、餘額）。使用者應該能夠打開瀏覽器，訪問支援以太坊的網站，並進行交易，而無需產生超出其分配的匿名等級的穩定、可連結的可區分訊號（也無需使用者了解底層機制）。 Etherveil 以所有可觀察執行層面的確定性約束強制執行取代了機率隱私機制。
系統不變量
不變式：所有可觀察的瀏覽器 API 必須解析為同一指紋設定檔類別中使用者共享的有限等價類集合。
簡單來說：所有使用相同隱私設定的使用者在網站上看起來都完全一樣，因為瀏覽器會將所有可觀察的行為強制納入少數標準化的模式中。
建築學
┌────────────────────────────────────────────────────┐│ Etherveil Browser Shell (Firefox/Tor Fork) │├───────────────────────────┬────────────────────────┤│ Execution & Fingerprint │ Kohaku Engine ││ Normalisation Layer │ (Wallet + Tx) ││ (Tor Browser Base) │ │├───────────────────────────┴────────────────────────┤│ Network Privacy & Verification Layer ││ Tor/Optional Mixnet, Helios Light Client ││ ERC-4337 Bundler Relay │└────────────────────────────────────────────────────┘ 指紋歸一化層
Tor 瀏覽器已經解決了大部分棘手的指紋辨識問題；我們正在對其進行擴展，而不是重新發明輪子。主要的新增功能是我們稱為「指紋配置」的東西：一個固定的、預先計算好的瀏覽器可觀察對象的等價類，它由一個滿足約束的元組構成，該元組基於從經驗分佈中導出的相關瀏覽器信號，並根據瀏覽上下文進行分配，並且在會話生命週期內保持不變。這確保了跨欄位的一致性（例如時區、區域設定和語言的一致性），並防止了獨立屬性欺騙。
關鍵的設計決策在於，這並非基於使用者配置或執行時間隨機化。隨機化實際上會適得其反：如果頁面載入之間畫布噪音種子發生變化，這種變化就會留下痕跡。相反，每個配置檔案都是從真實世界分佈中離線生成的一致快照，而非在運行時採樣，其選擇旨在最大化其所屬匿名集的大小。如果某個網站在指派的設定檔下發生故障，整個瀏覽上下文將在另一個相容的類別下重新啟動。會話期間不會發生任何變更。
透過確定性 API 攔截和重寫（而非內容腳本，內容腳本是可以偵測到的），在Gecko / SpiderMonkey層級對錶面進行歸一化：
-
navigator.*：用戶代理、平台、硬體並發性、裝置內存 Intl/Date：時區、區域設定、語言協商標頭- Canvas/WebGL：每個設定檔都有確定性的輸出；供應商和渲染器字串與類別分佈對齊
screen.*，devicePixelRatio- WebRTC ：ICE候選被抑製或標準化
- 高熵 API（音訊、字型、效能計時）：依設定檔類別量化
所有高熵 API 要么被量化，要么被統一，要么被映射到配置文件限定的等價類中。
儲存與互動隔離
儲存（ IndexedDB 、 localStorage 、cookie、快取）按來源和使用者設定檔進行分區，避免跨設定檔洩漏。除了儲存之外，交互訊號（滾動時間、指針移動、按鍵節奏）也在有界隨機模型中進行平滑和量化處理。目標是在不影響瀏覽器使用體驗的前提下，將行為熵降低到足以抵禦生物特徵重辨識的程度。可用性與熵之間的權衡是該系統的核心開放設計參數。
Kohaku錢包引擎
該錢包是瀏覽器原生子系統，而非擴充程式。瀏覽器向去中心化應用程式（dApp）公開單一的交易API，並且有意不透露特定交易是私下執行還是公開執行。這種區別是引擎的實作細節，dApp無需了解。
dApp -> Wallet API -> Kohaku Engine -> Privacy Relay -> Chain| 成分 | 角色 |
|---|---|
tornado-cash | 預設屏蔽交易層 |
provider | 統一 RPC（Helios/外部節點/本地客戶端） |
pq-account | 後量子ERC-4337預設帳戶類型 |
所有新帳戶預設都是pq-account智慧帳戶。 UserOperation使用者明確選擇公開交易流程，否則交易會透過 Tornado Cash（或更一般地說，透過抽象的零知識保護層）進行路由。 UserOperation 透過 Tor 路由的 ERC-4337 打包器提交，因此使用者的 IP 位址永遠不會與公共交易池中的任何交易關聯。
網路隱私層
網路協定棧繼承自 Tor 瀏覽器並進行了擴充：
- Tor（預設）：按來源隔離電路；所有流量和 DNS 完全路由。
- Mixnet（可選）：增強元資料抵禦時間關聯攻擊的能力，但會增加延遲；是否應為可選功能或預設功能尚未確定。
- Helios 輕客戶端：透過同步委員會證明進行本地以太坊狀態驗證，無需依賴中心化的 RPC 提供者； ENS解析僅透過 Helios 進行。
- 流量整形：確定性延遲填充和請求批次以降低時間相關性
威脅模型
該瀏覽器旨在防禦：
- ISP和出口節點流量分析
- 透過 Canvas、WebGL 和其他高熵 API 進行跨站指紋識別
- RPC端點監控（將查詢傳送至Infura/AlchemyETC）
- 鏈上地址聚類和交易圖分析
- 行為生物特徵重識別（有限緩解）
它無法完全解決（也不聲稱能夠解決）具有完全網路可見性的全球被動攻擊者的攻擊、作業系統或硬體級側頻道，或用戶操作安全故障。
非進球
為了保持設計的一致性，以下幾點明確排除在外：
- 擴充相容性：WebExtension API 重新引入了身分錶面，這將破壞指紋模型。
- 使用者可控制的指紋調整：匿名性保證取決於使用者之間無法區分，而不是個人化自訂。
- 選擇加入或「盡力而為」的隱私模式：這種模式只有在統一執行的情況下才能奏效。
- 向去中心化應用程式（dApp）公開執行模式（私人或公共）
延遲設計問題
實施前需要做出一些決定，但目前還沒有明顯的正確答案：
- 設定檔Persistence：同一設定檔是否應該在不同會話中分配給相同來源，還是應該在每個會話中輪換使用？同一來源保持一致性更有利於可用性；輪換使用則更有利於防止關聯。
- Mixnet 預設設定：以 Tor 為基準，Mixnet 作為選用功能，還是預設啟用，並為對延遲敏感的情況提供備用方案？
- 交互強化：行為熵抑制和可用性之間可接受的權衡點在哪裡？
- Web相容性：某些網站在嚴格的指紋類別下會顯示異常。當沒有相容的高用戶群體設定檔類別能夠正確渲染網站時，應該如何升級解決？
