EIP-8182：为以太坊添加隐私转账

EIP-8182 是一个草案提案，如果被采纳，它将使私密转账成为 Ethereum 的原生组成部分。以下是支持它的理由。

Ethereum 每年结算数千亿美元，但几乎每一笔交易都是公开的。你的余额、你发送的每一笔付款、每一个交易对手——全部都会被广播，并永久保存。在任何其他金融系统中，这都是不可想象的。

几乎所有在 Ethereum 上工作的人都同意，这种情况需要改变。2025 年 4 月，Vitalik Buterin 呼吁将隐私工具直接构建进现有钱包中：

将隐私工具（例如 Railgun、Privacy Pools）集成到现有钱包中。钱包应该有 shielded balance 的概念，而且当你向别人发送时，应该有一个“从 shielded balance 发送”的选项，最好默认开启。

一年后，这还没有发生。隐私协议确实存在，但在 2025 年，Ethereum 交易中私密交易的比例不到 1/10,000——仍然低于 2020 年的峰值。

这与它应有的水平相差几个数量级。没有任何其他金融系统会把每一笔付款都公开广播。Ethereum 不应该是例外。

为了弥合这一差距，Ethereum 需要一种新方法：EIP-8182。

为什么我们需要一种新方法？

要让钱包添加私密发送功能，需要有一个标准，就像 ERC-20 一样。隐私领域还没有出现这样的标准。

为什么没有？有两个结构性问题：

匿名集的“先有鸡还是先有蛋”问题

Ethereum 上的隐私是通过将资金汇集在一起实现的：共享同一个匿名集的用户越多，追踪任何单笔交易就越困难。更大的资金池能为每个人提供更好的隐私。将用户分散到多个资金池会削弱隐私。

这使得隐私应用特别难以构建。一个新应用无法为最初的用户提供隐私——而没有隐私，就不会有人加入。一旦某个资金池形成，用户就很难离开，即使是为了一个更好的应用，因为离开意味着放弃这个资金池规模带来的隐私。

因此，拥有最大资金池的应用往往会一直保持最大，不管产品质量如何。而且隐私应用越多，每个资金池就越小，对所有人的隐私都越差。在这个市场中，竞争反而会让用户处境更糟。

私密资金必须拥有与公开资金相同的安全模型

隐私系统需要不断演进——漏洞会被发现，加密技术会进步，标准会改变。但演进需要一种升级机制，而在应用层系统中，这种机制属于某个特定群体：multisig 签名者、token 持有者、DAO 等。

Ethereum 上的公开转账并不需要这种信任。私密转账的默认方案也不应该需要。

任何隐私标准在解决这两个问题之前，都不可能成为默认方案。

将隐私构建进 Ethereum 协议

EIP-8182 将一个共享的 shielded pool 直接放入 Ethereum：一个位于固定地址的系统合约，再加上一个 ZK proof-verification precompile，并且只能通过 hard fork 升级。这解决了两个问题：一个共享的匿名集，以及 Ethereum 自身的信任模型。

一个共享标准。钱包只需集成一次，用户就可以向任何 Ethereum 地址进行私密发送。无需在互不兼容的协议之间做选择。

一个共享匿名集。所有集成的钱包和应用共享同一个资金池。不需要再去启动一个新的匿名集。每新增一个用户，都会让所有人的隐私更强。

Hard-fork 治理。这个资金池没有 admin key、没有治理 token，也没有链上升级机制。它通过 Ethereum 的 hard-fork 流程演进——也就是治理协议中其他所有变更的同一种机制。

当这些障碍被移除后，应用层就可以围绕用户真正关心的事情展开竞争：钱包 UX、证明体验、认证方式、开发者工具等。

你可以用 EIP-8182 构建什么

有了 EIP-8182 作为原语，开发者就可以构建原生于 Ethereum 的私密发送功能。

发送到任意 Ethereum 地址

接收方就是现有的 Ethereum 地址和 ENS 名称——不需要单独的隐私专用地址格式，也不需要链下协调步骤。接收方注册一次，从那以后，任何人都可以使用他们已经在其他所有场景中使用的地址，向他们进行私密发送。

使用你现有的钱包

私密转账需要 zero-knowledge proofs，而大多数钱包无法生成它们。

EIP-8182 将授权与 proving 分离。你在钱包中签署交易细节，然后可选择将其发送给一个远程 prover，由它生成 proof 并代表你提交交易。

可定制的授权——而不会碎片化隐私

通过 account abstraction，公开的 Ethereum 正在摆脱单一私钥认证模型。私密转账也需要支持同样的灵活性。

EIP-8182 让授权完全可定制。任何人都可以创建新的授权方式——passkeys、multisig、social recovery——而它们全部共享同一个匿名集。你的认证方式本身也是私密的：任何观察链上数据的人都无法知道你使用了哪种方式。

Swap 和 reshield

私密资金可以离开资金池，与任意公开的 Ethereum 智能合约交互，然后再回到资金池——全部在单笔交易中完成。一个常见流程是将 token A unshield 到一个 helper contract，在 DEX 上将其 swap 成 token B，然后再把 token B 原子性地存回资金池。

Swap 本身会像任何 DEX 交易一样在链上可见，但你的身份和 reshield 后的目标地址仍然是私密的。这就是 synchronous composability——隐私保持与 Ethereum 的应用层相连接，而不是与之隔离。

接下来是什么

EIP-8182 目前是 Draft。要帮助推动它前进：

• 在 eip8182.com 了解更多
• 阅读 EIP-8182 spec
• 查看 EIP-8182 reference implementation
• 在这里回复或私信我反馈

FAQ

更详细的 FAQ 可在 eip8182.com 查看。

什么是公开的，什么是私密的？

隐私模型：

• 存款会在链上暴露存款人、token 和金额，但接收方的新 note 保持私密。
• shielded 转账会在链上隐藏 token、金额和交易对手信息。
• 提现会暴露被提取的 token、金额和接收地址。

这意味着该设计会把核心转账本身隐藏在资金池中，但并不试图隐藏价值进入或离开资金池这一事实。

这与 Tornado Cash、Privacy Pools、Railgun 和 Aztec 有什么不同？

Tornado Cash Classic 是一个存款/取款 mixer。一次转账看起来是这样的：发送方公开存款，等待，然后由接收方公开取款。隐私来自切断接收方和发送方之间的联系，这也是 classic pool 使用固定面额的原因。EIP-8182 试图做的是更广泛的事情。它旨在支持私密的池内转账，也就是说，一旦资金存入，它们就可以在不暴露发送方、接收方或金额的情况下被转移。classic pool 合约也是不可变的，因此如果它们的密码学假设发生变化，用户会迁移到新的资金池或版本，而不是就地修补旧的 classic pools。

Privacy Pools 与 Tornado Cash 类似，但支持部分提现和 dissociation：用户可以选择拒绝来自已知坏 actors 的存款的资金池，并且可以公开证明他们的提现不来自坏 actors。EIP-8182 在协议层面不提供这两者。应用可以在其上构建 dissociation proofs，但共享资金池本身不能被过滤。

Railgun 是最接近的比较。与 EIP-8182 一样，Railgun 是一个多资产 shielded pool，支持私密的池内转账，而不仅仅是 mixer 风格的存款/取款隐私。EIP-8182 也采用了 Railgun 支持的相同原子性 unshield → public action → reshield composability 模式。主要区别在治理层面。Railgun 是可升级的，升级由 $RAIL token 治理。EIP-8182 则由 Ethereum 的 hard-fork 流程治理，这与用户已经在协议其他部分所依赖的信任模型相同。

Aztec 是一个为通用私密计算而构建的 L2。它是隐私应用的平台，而不是一个隐私应用本身——这意味着在 Aztec 上进行私密转账，需要找到一个运行在 Aztec 上的私密转账应用，存入其资金池，进行转账，然后由接收方提现。Ethereum 应用层今天面临的同样协调问题，也是 Aztec 应用层面临的问题。Aztec 针对的是另一个问题——通用私密计算——并且从设计上并不试图提供一个共享的私密转账默认方案，而这正是 EIP-8182 的目标。

如果我的钱包无法生成 ZK proofs 呢？

如果你的钱包无法生成 ZK proofs——或者你的设备性能太弱，无法生成——你可以把 proving 外包给一个远程 prover。

关键属性是将花费授权与 proving 分离。你签署一个 payload，精确描述交易应该做什么——金额、接收方以及任何其他参数——并选择一个内部 auth circuit，它只会批准与该签名匹配的花费。然后 prover 生成 proof，但只有当 proof 与你签署的意图一致时，它才有效。如果 prover 试图替换交易参数，proof 就不会通过验证。所以 prover 有计算的能力，但没有决定的权力。

限制在于，虽然远程 prover 不能花费你的资金，但它无法在不了解所证明交易细节的情况下生成 proof。远程 proving 以这些交易的隐私为代价。可以通过在委托后轮换 noteSecretSeed 来缓解这一点。

如果 proof-system 或 circuit 出现 bug 会怎样？

一个允许攻击者伪造 proof 的 soundness bug 会耗尽整个资金池。任何 shielded pool、任何层级都是如此。如果我们想要私密转账，就必须接受 soundness bug 是一种需要管理的风险。

层与层之间的关键区别在于恢复方式。具有快速升级路径的应用层资金池可以快速修补，但前提是某个人持有改变规则的权力——这是一种永久性的信任假设，无论是否存在 bug 都会存在。EIP-8182 用消除这种信任假设来换取更慢的应急响应，并通过 Ethereum 的 hard-fork 流程来应对 bug。

EIP-8182 的系统合约方法的一个好处是隔离性。资金池中的 bug 最多只会影响资金池中持有的资产。它不可能凭空生成 ETH，也不可能危及资金池自身状态之外的任何东西。

EIP-8182 是否提供无条件隐私？

是的。你不必证明自己的清白就可以使用这个资金池。

但如果你想公开将自己与特定存款解除关联（例如可追踪到已知坏 actors 的资金），你可以这样做。应用可以使用链下 proof-carrying data 在其上构建可选的 dissociation 工具（Derecho: Privacy Pools with Proof-Carrying Disclosures，Beal 和 Fisch，CCS 2024）。这些工具存在于应用层，不会改变协议。

法律风险怎么办？

EIP-8182 假定 private transfer 功能可以在 Ethereum 上合法存在，并且认为在协议层构建比在应用层构建更好。如果这个假设不成立，我们也不应期待应用中会出现私密转账——无论 EIP-8182 是否落地。

EIP-8182 的 shielded pool 会收取协议费用吗？

不会。EIP-8182 不会对存款、转账或提现收取 protocol fee。资金池本身不抽成。用户仍然支付正常的 Ethereum gas，而某些钱包流程可能会涉及 proving 或 relaying 成本，但协议本身不会对私密转账额外收费。

• 原文链接： x.com/dumbnamenumbers/st...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～