为什么用户（尚未）使用隐私：来自链上隐私体验的见解

妮可·耶

研究目的

尽管人们对链上隐私的意识日益增强，但隐私工具的采用率仍然很低。许多用户表示他们关心隐私，但在隐私方面投入的精力却很少，通常发现现有工具过于复杂或不透明。

本研究探讨了具有不同技术背景和隐私需求的用户如何体验新兴的以隐私为中心的产品。

我们的假设是，隐私用户体验的需求因用户资料和用例而异，一刀切的方法限制了采用。我们试图绘制用户旅程图，发现痛点，并识别设计机会和技术挑战，以改善整体体验。

主要发现和痛点

通过定性访谈，我们确定了所有测试工具中反复出现的主题：

1. 不明确的隐私边界： 用户误解了实际上的隐私内容和时间。许多人认为“屏蔽”意味着完全匿名。
2. 没有证据的信任： 用户依赖项目声誉而不是可验证的证据； 他们希望有链上或第三方提供的可信度证明。
3. 过于技术性的设置： 技术和非技术用户都发现设置流程在认知上负担过重且容易出错，通常需要高级步骤（ENS、RPC、手动部署）。
4. 不安全的默认设置和反馈缺失： 隐私选项是隐藏的或默认为公开。用户希望有可见的隐私指示器和持久的确认。
5. 验证焦虑： 对不可逆转操作的恐惧使用户犹豫是否使用或测试具有真实资金的隐私工具。
6. 特定于上下文的隐私动机： 用户希望在特定场景（例如，投票、大额转账）中实现隐私，而不是普遍适用。
7. 教育差距： 即使是高级用户也难以理解这些概念（隐身地址、中继器、屏蔽投票），突出了对分层、易于理解的解释的需求。
8. 期望的品质： 透明度、控制、安全网（测试模式）和项目寿命始终建立信任。

总体结论

用户不是拒绝隐私，而是拒绝不可见、未验证或认知负担过重的隐私。为了扩大采用范围，隐私工具必须从“高级用户密码学”演变为可信、可测试和以人为本的基础设施。

致谢

如果没有我们所研究的隐私项目的开创性工作，这项研究是不可能完成的：

Fluidkey

、Railgun、Privacy Pools、Flashbots 和 Shutter (Shielded Voting DAO)。

这些项目代表了以太坊生态系统中隐私创新的最前沿。我们的意图不是批评，而是向已经在塑造私有、可验证和尊重用户的区块链体验的领导者学习。我们非常感谢他们不断努力使隐私对所有人可用和可访问。

方法论

为了探索用户如何与不同的以隐私为中心的链上工具交互，并了解他们对使用这些工具的看法、挑战和动机，我们进行了 五次一对一定性访谈。

每个参与者都被分配了 一种隐私产品（MEV 保护 (Flashbots)、Shielded Voting DAO、Privacy Pools、Fluidkey 或 Railgun），以及 特定的使用任务（例如，创建帐户并存入资金）。参与者被要求在完成任务时 大声思考，而面试官则观察并探询以阐明他们的推理、期望和情感反应。

完成任务后，参与者反思了他们的 整体体验，讨论了哪些感觉直观或令人困惑，哪些建立了或降低了信任，以及他们是否会考虑再次使用该工具以及在什么情况下使用。

专题亲和力映射

1. 将相似的观点分组，如“令人困惑的信任边界”或“害怕在不知情的情况下泄露信息”
2. 对每个反馈来自哪个产品进行颜色编码，以便你可以看到跨类别的模式

模式 1：围绕实际隐私内容的困惑

行为：用户经常误解哪些数据或操作受到保护，哪些被暴露。

• 许多人认为“屏蔽”意味着完全匿名，却发现投票或交易是_暂时_或_部分_私密的。
• 参与者不确定隐私何时适用。 例如，前端、中继器或 RPC 是否仍可能泄露信息。

引用和证据：

“我以为屏蔽意味着我的投票永远是私密的…… 我必须悬停鼠标才能看到详细信息，这很奇怪。”

快照用户界面

“如果我使用 Alchemy，会有很多泄漏…… 还有什么意义呢？”

隐私池 Github

设计含义：

→ 工具需要明确的、上下文相关的隐私指标（例如，“你的地址在公开阶段之前是隐藏的”）和 对隐私边界的简单语言解释。

模式 2：缺乏信任透明度

行为：信任决策由品牌声誉驱动，而不是由可验证或可见的保证驱动。

• 用户“信任”Flashbots 或 Railgun 是因为他们听说过这些项目，而不是因为界面提供了证明。
• 即使是技术上高级的用户也会质疑该服务保留了多少托管或数据。

引用：

“我信任 Shutter 是因为个人风险很低，而且我听说过他们，而不是因为用户界面证明了任何东西。”

“我以前听说过 Railgun，所以我更信任它一点”

“如果上次发布是在三个月前，而且没有很多星星，我就没有信心。”

Railgun Github

“只有你和 Fluidkey 才能看到你所有的交易…… Fluidkey 团队？ 运营商？ 这是什么意思？”

Fluidkey 用户界面

设计含义：

→ 构建 可见的信任提示（审计、社会证明、项目年龄）并集成 可验证的信任机制，如链上证明或审计链接。

模式 3：过于技术性的设置和认知过载

行为：参与者发现设置流程零散、冗长或不透明，尤其是在需要购买 ENS、部署代币或管理 RPC 时。

• 即使是高级用户也注意到“大量的点击和签名”，但对每个操作的意义却很少反馈。
• 非技术用户很难理解为什么需要新的钱包、种子或面额。

引用：

“有大量的点击和签名，我什至不知道我同意了什么。”

“为什么我需要购买 ENS 才能进行测试？”

快照用户界面

快照用户界面

“我永远不会信任在线生成的种子，这是加密安全的基础。”

隐私池用户界面

设计含义：

→ 通过引导式入门、渐进式披露和 用于安全实验的测试模式 来简化设置。

模式 4：可用性摩擦：默认设置、导航和反馈

行为：用户难以处理隐藏的控件、不明确的默认设置和缺失的确认。

• 隐私选项被埋没（“投票选项卡中的小文本”）。
• 默认设置经常破坏隐私（“任何”= 公开）。
• 反馈是短暂的或不明确的（“确认消失得太快”）。

引用：

“默认设置很重要，它应该默认设置为屏蔽。”

“隐私控件在哪里？ 只是这个很小的文本。”

快照/Shutter 用户界面

“如果默认情况下是私密的，那就太完美了。 我不应该考虑它。”

Flashbot 用户界面

设计含义：

→ 采用 默认隐私，确保 清晰的可视状态指示器，并为关键操作维护 持久的确认消息。

模式 5：验证焦虑和害怕损失

行为：用户害怕做不可逆转或未验证的操作（例如，在没有可见确认的情况下发送资金或证明）。

• 一些人希望在冒真实资金风险之前进行测试模式或试运行。
• 即使是自信的用户也会仔细检查合约地址或等待看到资金重新出现。

引用：

“没有测试模式。 我不会通过未经测试的东西发送 1 ETH。”

Flashbot 用户界面

“我想在确认交易之前看到合约。”

隐私池交易的 Etherscan

Etherscan 上的隐私池合约

“我不会下载任何随机的东西，即使在这台机器上也是如此。”

Railgun 用户界面

设计含义：

→ 提供 沙盒或测试网络、可验证的确认 和 最终确定之前的交易可见性。

模式 6：特定于上下文的隐私动机

行为：使用隐私工具的动机因上下文而异。

• 一些人希望隐私用于治理（投票），另一些人仅用于大额转账或身份分离。
• 技术用户认为“合规隐私”是“不是真正的隐私”。

引用：

“合规隐私就像放弃，它根本不是真正的隐私。”

“对于大额资金转移，我会提前计划，所以等待不是大问题。”

隐私池用户界面

设计含义：

→ 提供 灵活的隐私级别 和 上下文感知的默认设置，以适应意图（例如，治理与支付）。

模式 7：教育差距和心理模型不匹配

行为：即使是高级用户也难以阐明隐身地址、屏蔽投票或中继器等功能如何工作。

• 模棱两可的标签（“高级用户”、“屏蔽”、“ASP”）会造成焦虑或疏远。
• 用户欣赏内联解释和逐步指导。

引用：

“普通用户可能不知道隐身地址是什么，即使我不确定我是否可以定义它。”

Fluidkey 用户界面

“‘高级用户’让我觉得我可能不够技术。”

Fluidkey 用户界面

设计含义：

→ 使用 分层教育（简单的前期信息，可扩展的细节），避免使用术语，并提供 交互式入门导览。

模式 8：隐私工具中所需的品质

行为：在所有访谈中，用户始终重视：

• 透明度： 显示正在发生的事情
• 控制： 验证和自定义的能力
• 安全网： 测试模式、确认和清晰的恢复路径
• 声誉和寿命： 较旧、经过审计、广泛使用的项目感觉更安全

引用：

“任何让我感到更安全的东西都很重要，比如审计链接、社会证明。”

Fluidkey 用户界面

“已经存在更长时间的旧应用程序感觉更安全。”

设计含义：

→ 将隐私构建为_可信的基础设施_，强调稳定性、安全性和证明，而不是抽象。

映射到痛点与机会，并提供设计建议

总结我们将主题确定为痛点和机会

行动号召：塑造链上隐私的未来

这项研究是对生态系统的公开邀请。我们希望设计师、开发人员、研究人员和隐私倡导者可以合作解决此处发现的挑战。

为未来的工作做出贡献：

1. 识别技术挑战

许多用户痛点似乎与用户体验相关，但根源于深厚的技术限制。 构建可验证的隐私、安全测试和无缝默认设置需要密码学创新、基础设施演进和更好的开发者工具。

2. 扩展定量理解

通过大规模定量分析来补充这项定性研究（我们正在 Devconnect 积极收集回应！填写 此处的调查 ，以便我们更好地了解你对隐私工具的看法）。 衡量并优先考虑跨用户群体的隐私需求、态度和使用障碍。 例如技术与非技术、高隐私动机与低隐私动机，从而指导投资在何处产生最大的影响。

3. 原型和分享解决方案

试用“默认隐私”界面、testnet 安全流程和可验证的信任提示。 公开出版学习内容，以加速共同进步。

4. 建立一个开放的隐私用户体验社区

如果你是一位对隐私体验充满热情的设计师、开发人员或研究人员，请贡献想法、案例研究或实验。 共同努力，我们可以让隐私成为默认的期望，而不是事后的想法。

5. 拓宽角色和功能覆盖范围 本研究侧重于特定的用户角色和产品功能。 例如，治理工具中的 DAO 管理员或隐私钱包中的存款流程。 未来的研究应探索参与者和功能的整个生态系统，以提供跨上下文的隐私体验 (PX) 的更全面的视图。

更多文章 查看全部

2025 年 12 月 10 日\ PSE 2025 年 11 月通讯PSE 团队\ \ PSE 团队一直在忙什么，以及展望 Devconnect

2025 年 11 月 11 日\ 2026 年私有投票状态私有治理团队、Shutter Network、John Guilding、Anton Valov、Nico Serrano\ \ 2026 年以太坊上私有投票协议的博文公告。

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

Discord Github Twitter Youtube RSS 工作

反馈 隐私政策 使用条款

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