重要提示：本文档尚处于开发阶段，仅代表早期架构方案。它定义了预期的系统边界和设计原则，但并未明确最终实现方案或安全保证。请注意， 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相容性：某些网站在严格的指纹类别下会显示异常。当没有相容的高用户群体设定档类别能够正确渲染网站时，应该如何升级解决？
