PSE 调研揭示隐私转账领域的技术瓶颈与挑战

针对隐私转账用户研究进行的 38 次访谈摘要

隐私转账用户研究

为了寻找隐私转账领域的技术问题，我们与该生态系统中的团队进行了 38 次用户访谈。这项工作由隐私转账工程团队承担。隐私转账工程团队隶属于 PSE 的私人写入团队。该团队于 2025 年 11 月成立，在过去的 6 个月里，我们进行了用户研究、研究了不同的隐私协议，并开展了一些有针对性的探索。我们将很快发布更多关于我们工作成果的内容——请在未来几周保持关注。

此次用户研究的核心目标是找出团队面临的技术问题。这将有助于我们理解这个领域，为生态系统积累共享知识，并指导我们自身的路线图。通过发现重要问题，我们能够有针对性地投入精力。我们还借机询问了团队希望看到核心协议发生哪些变化，以帮助他们的项目，并全面实现隐私转账。我们访谈的是面向最终用户构建的协议团队——而非最终用户本人。对话形式自由，但主要围绕三个问题展开：

1. 他们面临的技术问题
2. 他们希望看到的核心协议变化
3. 他们面临的非技术问题

在接受访谈的项目中，大约四分之一拥有某种基于 ZK 的屏蔽池架构。约有 3 个是隐身地址协议，约 4 个基于 FHE，约 3 个基于虫洞，约 7 个是 L2，约 3 个使用 TEE，其余则属于其他特定技术栈和混合技术协议的长尾。例如，一些团队采用了多种技术的组合——ZK + 隐身地址、ZK + FHE 等。因此，基于 ZK 的屏蔽池和 L2 占了样本的很大比例，并相应地影响了结果。

这并不构成代表性的定量数据，但可用于评估在上述混合团队和技术中最常被提及的问题。所面临的技术问题和所请求的核心协议变更不应被解读为最重要的工作方向或对这些变更的投票。

关于技术问题，ZK 验证和证明的成本与性能被列为最突出的问题。此外，隐私转账如何与 DeFi 组合是另一个重要问题。其他经常被提及的问题包括：存入/屏蔽和提取/解除屏蔽时的隐私泄露；钱包对隐私功能的支持不足；依赖中继器和协处理器网络等外部服务和网络。提及最多的非技术问题是监管不确定性和寻找产品市场契合点。

技术问题

多个类别下提出了一系列技术问题。如上所述，受访项目样本偏向于基于 ZK 的项目，但重要的重复主题包括：降低用户使用隐私协议的成本、减少信任假设，以及与 DeFi 的组合。

成本与性能

ZK 证明验证 Gas： 在以太坊上验证零知识证明的链上 Gas 成本过高。验证 Gas 和证明生成时间被多个团队确定为最高优先级的瓶颈——这也是一些团队选择放弃 ZK 转而采用其他方法的关键原因。目前，验证一个隐私转账的 Groth16 证明大约需要数十万 Gas，而验证一个小电路的 Halo2（KZG Plonk）证明可能需要约 100 万 Gas。

ZK 证明生成时间： 在用户设备上生成零知识证明的计算量很大。客户端侧证明生成速度太慢，尤其是在移动设备上。例如，椭圆曲线配对操作是用户设备上的特定瓶颈。服务器端证明是一种直接的解决方案，但会引入审查风险，并且如果证明数据未加密发送，可能会泄露用户的私有状态。一些协议要求证明生成时间在几十秒的量级。子秒级证明被认为是解决此问题的阈值。

哈希函数效率低下： 原生哈希函数（Keccak）在 ZK 电路中证明效率低下。缺乏对 ZK 友好哈希函数（如 Poseidon）的原生支持。这导致电路规模和证明时间增加。一个 ZK 友好的原生哈希函数将显著缓解这种低效。

以太坊存储证明成本高昂： 目前，证明以太坊状态相关的内容既慢又昂贵。这阻碍了需要存储证明（例如虫洞）的隐私设计。

大尺寸密文： 大尺寸密文（特别是针对 FHE）不适合以太坊的存储模型。项目依赖事件或链下存储（链上存储哈希承诺）。根据所使用的方案，FHE 密文的大小可能在数 KB 范围内。

吞吐量： 多个团队强调，以太坊吞吐量、Rollup 容量和 FHE 协处理器吞吐量无法满足隐私保护支付轨道所需的规模。一些 FHE 项目可以达到数百 TPS，但需要数万 TPS。对于某些项目，当前吞吐量足以满足需求，但无法满足未来的预期需求。

长区块时间和慢最终确认： 对隐私本身不一定重要（对依赖跨多个区块发送交易以获得最大隐私的字节码混淆技术很重要），但对支付而言通常很重要。

状态、组合性与集成

碎片化的匿名集： 屏蔽池在不同 dapp 和链之间是碎片化的，这降低了所有用户的有效匿名集。每个新的隐私协议都必须自行引导其匿名集。这也导致了围墙花园效应。

隐私协议状态增长： 状态增长（例如无效器状态树增长）是一个长期的扩展问题。与常规转账（新状态按账户添加，每个新账户为该账户余额添加新状态）不同，基于 UTXO 的隐私转账协议使用承诺和无效树，每笔交易都会添加新状态。这是因为需要创建加密的 UTXO，并使用无效器标记为已花费以防止双重支付。

状态管理和同步可扩展性： 同步私有状态（扫描传入的票据/事件）是客户端的瓶颈。客户端设备必须扫描大量链状态才能构建其私有余额状态。这降低了用户体验，因为钱包用户必须等待扫描完成才能看到最新余额。PIR 或 OMR 的进步可以解锁更可扩展的方法，而使用像 Zcash 的 Project Tachyon 中概述的 oblivious 同步，为处理核心协议状态增长提供了一条前进道路。

DeFi 可组合性： 为 DeFi 操作包装/解包代币会泄露隐私和意图，并破坏与现有协议的可组合性。智能合约无法轻易与加密/私有余额交互。屏蔽资产缺乏未加密的余额，隐身地址余额缺乏统一的单一余额，这两者都与 AMM 和借贷协议等现有协议设计相冲突。DeFi 操作本质上比常规转账具有更丰富的交易数据，这使得隐藏更难，分析更容易。另一种表述缺乏可组合性的方式是，私有状态是孤立的，而合约状态通常是共享状态。这种状态模型和缺乏可组合性限制了应用程序的设计空间。多个团队将此问题视为一个困难且重要的问题。

存入/提取隐私泄露： 多个团队将隐私系统的入口和出口点识别为主要隐私泄露点，而非协议本身。例如，存入后立即提取使得对该身份的分析更加直接。流动性和匿名性分散在不同链上——跨链桥接也会泄露隐私。

账户方法更难实现完全隐私： 当使用基于账户的隐私方法时，例如

ERC-7984: 机密同质化代币

，与基于票据的多资产屏蔽池相比，隐私的不同方面更为困难。基于账户的方法简化了与 EVM 组合性的许多方面，但带来了其他权衡。代币合同明确定义了资产类型，因此资产隐私很难实现。匿名性比机密性更难实现，因为状态访问模式会揭示哪些状态被访问，随着时间的推移，这种分析可以将特定账户状态与特定身份关联起来。

工具： 以太坊开发者工具缺乏对隐私转账和私有合约状态的支持。

钱包、密钥管理与标准

缺乏原生钱包支持： 主要钱包没有原生集成每个 dapp 的新地址等隐私功能，以及对隐私转账的访问。这迫使依赖特定的 dapp，并严重损害了用户体验。

密钥管理复杂性： 用户可能被迫管理多个密钥（花费密钥、查看密钥），这是一个用户体验障碍。一些协议通过从现有用户账户派生额外秘密来解决此问题。

使用隐身地址花费资金： 私下接收资金（例如通过隐身地址）已解决，但花费这些资金而不链接到公开的 Gas 支付地址仍然困难。在私下接收资金后，使用这些资金而不意外揭示关联仍然很难（转移资金、提现、与应用程序交互）。缺乏统一余额也使得与协议交互更加困难，因为像 AMM 这样的协议假设一个单一余额。

硬件钱包缺乏对 ZK 友好密码学的支持： ZK 协议偏好 ZK 友好的哈希和签名，以使证明生成高效。硬件钱包不支持 BabyJubJub 曲线上的 EdDSA 等 ZK 友好的曲线和签名方案。

传统查看密钥模型可编程性不足： 拥有一个可以完全查看账户历史的单一查看密钥的模型与合规要求不兼容。合规要求细粒度的控制，并能向特定对手方进行表达性的选择性披露。

缺乏标准： 关于隐私代币、合规性或钱包交互的标准有限或完全没有。这导致生态系统碎片化。

安全性与额外信任假设

依赖中继器： 为了断开链接或为私人交易支付 Gas，协议通常依赖第三方中继器。这引入了中心化和审查风险。如果 Gas 赞助是可追踪的（这通常是情况——至少对中继器实体而言），隐私泄露仍然存在。

依赖外部网络： 加密代币和许多隐私协议依赖外部网络来提供加密/解密服务——例如 FHE 协处理器和 TEE。这引入了审查和隐私风险。例如，FHE 协处理器使用门限加密方案和一个委员会来执行解密，与发送常规以太坊交易相比，增加了额外的信任假设。需要注意的是，这些外部网络在其他领域提供了显著优势，这使得它们对许多用例具有吸引力。FHE 允许可组合且可编程的加密智能合约，而 TEE 则以硬件信任假设为代价提供了无与伦比的性能。

与不可花费地址的碰撞风险： 基于虫洞的项目都存在相同的安全问题。每个不可花费地址只有 80 位熵，这意味着攻击者有可能生成一个与不可花费地址碰撞的私钥并声明资金。虽然每次攻击仅限于单个地址，但这种安全级别不够高。一种缓解措施是为每个地址添加少量工作量证明，以增加额外 12 位安全性，使每个地址达到 92 位。虽然有所帮助，但仍然不够。作为参考，L1 遵循典型的安全指南，目标是 128 位安全性。

请求的核心协议变更

用于 ZK 效率的预编译： 引入针对 ZK 友好密码学原语（例如 Poseidon 哈希、特定椭圆曲线操作、Bulletproofs）的预编译，以降低验证成本。

状态树改进： 多个团队要求改进以太坊状态树——使用 Poseidon 或其他 ZK 友好的树哈希，以及二叉树或其他更便于证明的结构。

原生屏蔽池： 请求在协议层面提供一个屏蔽池（类似于 Zcash 模型），用户可以将资金原生移入私有状态——包括对原生 ETH 转账和多资产屏蔽池的请求。

许多隐私协议可以共享的协议功能： 一个更通用的请求——共享原语以避免碎片化。例如，虫洞风格的原语，或一个共享的屏蔽池。

更好的存储证明原语： 使证明以太坊状态相关内容更容易且更便宜。

原生账户抽象： 对于实现隐私 Gas 支付（支付主）以断开支付者身份与交易费支付者的关联是必要的。

加密数据类型： 协议处理或指向加密数据类型的标准方式，使智能合约更容易与私有余额交互。当前智能合约无法将加密值作为一流数据类型表示。加密状态最终以字节形式传递，链下存储并链上存储承诺，或作为事件发出。一些 FHE 团队要求协议定义如何表示和访问加密数据，以便合约可以像目前与 ERC-20 交互一样与私有余额交互。ERC-7995 被提名为候选方案。

zkWormhole 支持： 对允许“可否认的”存入和提取的机制感兴趣。32 字节地址将解决 80 位安全问题。与此同时，一些团队强烈表达了对 L1 上虫洞的担忧和反对。这是因为使用虫洞获得的可否认性会将干净资金与非法资金混合。这与关于用户主权的某些理念相矛盾，即用户应该能够选择自己关联的资金。

更短的区块时间和最终确认： 虽然与隐私转账无直接关系，但更短的区块时间和更快的最终确认被认为是显著改善隐私支付用户体验的选项。

明确的不应更改协议之处： 尽管许多团队希望进行 L1 更改，但一些团队没有提出协议变更请求，或者只提出了一个请求。这主要是因为他们对核心协议没有意见，或者认为某些事情不够重要。虽然隐私转账、共享数据结构、提升性能等需求更加明确，但由于以太坊的状态模型，对通用私有合约状态的兴趣远不确定，并未被直接请求。如上所述，一些人反对提供可否认隐私转账的功能。

非技术问题

项目提出了一些非技术问题。这些不一定是像 PSE 这样的团队能够解决的问题，但了解这些约束是有益的，因为它们会影响技术实现。有趣的是，虽然所有团队都强调了技术问题，但许多项目表示，他们在业务中面临的最重要问题不是技术问题。团队已经构建了产品，认为技术权衡足以推向市场，现在正处理如何应对监管环境和实现产品市场契合。

监管不确定性： 团队不确定何种程度的隐私与合规是可以接受的。类似于 Privacy Pools 的关联集合几乎没有法律先例。机构希望更强形式的合规，这与追求无条件隐私产生紧张关系。

低需求和无产品市场契合： 叙事兴趣不一定转化为实际使用。公开兴趣与显示出的偏好之间存在错位。用户不愿意为隐私付费或忍受摩擦。团队报告称零售需求低，机构需求理论上很高但严格以合规为条件，且尚未大规模到来。一些机构需求是探索性的，并不紧迫。虽然一些团队提到了零售产品市场契合的缺乏，但对其他团队来说，有迹象表明存在产品市场契合。例如，一些大户愿意为每笔交易支付 25-50 个基点的隐私费用。

法律风险： 开发者担心如果他们的工具被非法行为者使用，会面临法律后果（制裁、执法行动）。这阻碍了开放、无许可隐私工具的开发，转而偏向合规隐私工具。在核心协议层面考虑隐私时，一些人强调这里也存在风险。主要交易所无法上架某些隐私资产，一个担忧是，足够强大的默认隐私设计可能会将 ETH 本身归入此类，影响以太坊的采用。

机构将隐私门槛设得过低的风险： 隐私是许多希望上链的机构的入场所需，项目正正确地为此类用户需求构建。吸引机构资本伴随着以牺牲个人用户主权为代价为它们构建的风险。例如，机构可能更关心作为机密性的隐私，而非作为匿名性的隐私。机构想知道信息“向谁、何时”披露，而不是完全匿名。机构也要求合规，而合规引入了可能损害用户隐私的审查向量。

流动性约束： 多个团队表示，隐私转账的一个实际障碍是流动性。隐私协议中需要更多流动性以提高有效匿名集大小，从而提升用户效用。主要对手方（如交易所、做市商、稳定币发行方和 TradFi 机构）选择将资本存放在何处将影响此问题，而它们本身也需要足够的流动性才能进入隐私协议。

隐私的优先级： 对于某些应用，隐私在后期阶段或完全不重要。随着产品发展和市场渗透增加，隐私将变得更加重要。

缺乏共享路线图或协调： 团队希望获得以太坊基金会级别的指导。许多团队询问我们对隐私转账的计划。团队还想了解未来与隐私相关的新功能，因为这会影响到他们的路线图。团队不想往错误的方向构建。注意这些访谈是在 L1 隐私转账被宣布为以太坊基金会 strawmap 的一部分之前进行的。 由于 L1 的具体隐私功能正在研究中，完全明确的共享路线图仍然缺失。

资源限制和可持续性： 许多团队规模较小，面临显著资源限制。小团队无法承担大规模重新设计或深层次的协议工作。由于资金跑道有限，他们需要处理较小的任务，时间跨度较短。审计仍然昂贵。一些隐私项目难以找到可持续的商业模式，通常依赖资助而非业务收入。

招聘优秀技术人才困难： 很难找到具有 ZK 等领域经验的有才华的开发者。开发者人才库很小。

热门话题（按团队提及次数排序）

38 次访谈中的大致提及次数。与其他类别相比，基于 ZK 的屏蔽池和 L2 在受访团队中占了很大比例。这影响了结果，以下表格不应被解释为来自所有可能隐私团队的代表性定量数据。

非技术问题出现的频率高于许多技术问题。提及份额最大的高级别话题是：隐私转账的成本与性能（作为几个不同问题提出）、与 DeFi 的可组合性、监管不确定性，以及寻找产品市场契合。

结论

用户研究揭示了许多问题，并显示出许多不同团队关注的重点。降低隐私协议的成本被反复提及，同时寻找与 DeFi 的良好组合方式以及一些非技术问题对团队也很重要。显然，隐私团队对 L1 层面的隐私存在需求——改善隐私协议的成本和性能，以及提供不同团队可接入的共享功能，是提及的显著高级目标。

关于请求的核心协议变更，团队希望进行变更以改善隐私转账的成本和性能，提供不同协议可插入的共享功能（包括原生隐私），原生账户抽象等。很明显，L1 层面有很多支持隐私的方式。好消息是，其中许多功能已经在以太坊路线图上。Poseidon 的一个变体将作为精益以太坊路线图的一部分落地，目前正在进行密码分析。期待已久的从 Merkle Patricia Trie 的迁移已列入计划，原生账户抽象提案正在推进，更快的最终确认和更短的 Slot 现在成为高优先级，目标是 3 Slot 最终确认。重要的是，L1 的隐私转账现在是一项有计划的功能。然而，这次升级将采取何种形式目前仍是一个开放问题。

下一步计划

隐私转账工程团队正在整理一份隐私转账状态报告，并附带一个实时仪表板，该报告将深入探讨各种不同的隐私转账协议。完成用户研究后，我们还对 L2 预编译进行了探索，以解决隐私协议成本问题，但后来因为我们认为目前这个想法还不够有用而放弃了。我们将接下来发布我们对 L2 预编译的探索，敬请期待将于 Q2 初发布的隐私转账状态报告。

更多文章 查看全部

2026 年 5 月 7 日
介绍 SpeakUp

早期预览 SpeakUp，这是我们在 PSE 为客户端侧、隐私优先的 WebAssembly 程序证明而原型的 zkVM……

2026 年 3 月 1 日
社交恢复 SDK：设计、实现与经验教训 Rasul Ibragimov

社交恢复是一种钱包恢复模型，其中受信任的守护者可以在所有者丢失密钥时帮助恢复访问权……

关于 项目 研究 生态系统 博客 主图

Discord Github Twitter Youtube RSS 招聘

隐私政策 使用条款

• 原文链接： pse.dev/blog/private-tra...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～