本文的观点和假设：

• 区块链网络中的一些隐私是必须具备的，而不是锦上添花的
• 区块链目前的透明性是更广泛采用的一大障碍
• 不同的用户和用例将需要不同级别的隐私。并非所有问题都需要使用同一个工具来解决。

普通用户是否关心隐私？

是的，但程度因人而异。

每个人或多或少都会关心隐私，我们在日常生活中也会对隐私做出某种默认的假设。例如，当你在公司Slack群组中发消息时，你默认认为只有同事能看到这些消息。同样，许多人可以接受信用卡公司或银行监控他们的交易，但绝不愿意向全世界公开他们的交易历史。

企业出于竞争、安全性和合规性等原因，对隐私的关注度更高，且通常比个人用户更愿意为此付出代价。

另一个重要的问题是：用户希望对谁保护隐私？

1. 网络中的其他用户和外部观察者
2. 提供服务的第三方和中介机构
3. 政府、政府机构以及大规模监控

对于大多数使用场景来说，第一个隐私需求是绝对必要的，如果我们接受较弱的隐私保障，这在今天的区块链网络中已经可以实现。第二个需求是整个行业正在努力的方向，以赋予用户更多控制权，避免公司未经许可利用我们的数据。而第三个需求——即对政府和政府机构的隐私保护——从监管和政治角度来看是最复杂的。

我们如何定义“隐私”？

隐私并不等同于秘密。隐私是指不希望让全世界知道的事情，而秘密则是不希望让任何人知道的事情。隐私是选择性地向世界展示自我的权力——《Cypherpunk’s Manifesto》（密码朋克宣言）

隐私是一个复杂的概念，涵盖了多个独立但相关的话题，比如数据主权（数据的个人所有权）、密码学等。此外，人们通常在不同的语境中较为随意地使用“隐私”一词，缺乏明确的定义，这使得围绕隐私展开讨论变得困难。像“机密性”（confidentiality，指“什么”）和“匿名性”（anonymity，指“谁”）这样的术语经常与隐私互换使用，尽管它们只是隐私功能中的一部分。

围绕隐私的一些关键问题包括：

• 如果需要，哪些信息可以被披露，以及可以披露给谁？
• 谁有权披露信息？
• 系统正常运作需要披露什么信息，以及应披露给谁？
• 对当前的隐私数据，有什么保障可以确保它在未来仍然保持私密？

基于这些问题，我们可以将隐私总结为一句话：隐私是指用户（数据的所有者）对其数据的共享情况、共享对象和共享条件拥有控制权，并且有强有力的保障确保被设定为私密的数据将始终保持私密性。

我们是否需要新的术语？

结合以上讨论，”隐私”这个词是否不适合我们想要实现的目标？或许是，也或许不是，这取决于你的视角。

一方面，“隐私”这个词似乎是二元的（某事要么是私密的，要么不是），但正如我们之前所提到的，它远比这要复杂得多。不同的信息可以是私密的（输入、输出、交互的程序等），某些信息对一个人来说是私密的，但对另一个人却是公开的，而且不同的隐私解决方案背后有各种信任假设。此外，“隐私”这个词可能带有负面含义，可能会让讨论偏离实际主题。

另一方面，“隐私”是一个广为人知的术语，已经深入人心。引入新术语可能会引发混淆，尤其是在没有一致意见的新术语应该是什么的情况下。试图用替代词语来绕过这个话题显得有些不诚实，我们应该能够直接讨论问题的本质。

作为协议工程师和区块链网络的构建者，从新角度看问题有助于我们发现新问题或揭示现有解决方案中的缺陷。一些替代术语，如“信息流控制”（信息隐私文献中常用的术语）或“可编程披露”（我们的建议），可能更好地捕捉到了隐私的细微差别。信息对某些人来说是私密的，对另一些人则是公开的，用户可以决定与谁共享哪些信息。

然而，为了避免不必要的混淆，我们将在本文中继续使用“隐私”这个术语。

Web2中的隐私与区块链网络中的隐私有何不同？

大多数互联网用户对Web2的“隐私”比较熟悉。在Web2中，我们的数据在传输过程中是加密的（如今高达95%的流量都是如此），并且数据对其他用户是屏蔽的，但会共享给可信的中介和服务提供商。换句话说，Web2中的“隐私”（即对其他用户的隐私保护）是通过信任中介来实现的。

这种方法赋予用户一定的控制权，允许他们在服务提供商之外与其他人共享数据。然而，这也意味着用户需要大量信任服务提供商，信任他们能安全地存储和正确地处理数据。此外，由于数据使用方式的透明度有限，用户只能希望服务提供商如他们所声称的那样行事（基于声誉的模型）。

区块链网络旨在减少对中介的依赖，并通过从基于声誉的模型转向经济或加密的保障，提供更强的保证。然而，分布式模型也带来了新的挑战，尤其是在隐私方面。节点需要同步并就网络的当前状态达成共识，当所有数据是透明的并且在所有节点之间共享时（现状），这相对容易实现。但当我们开始对数据进行加密时，难度就显著增加了——这也是大多数区块链网络今天仍然保持透明的主要原因之一。

为什么在区块链网络中实现隐私如此困难？

在区块链网络中实现隐私有两种方式：信任隐私（通过中介实现）和信任最小化隐私（非中介化）。

这两种方式各有挑战，但挑战的来源不同（意识形态 vs 技术）。信任隐私相对容易实现，但其保证较弱，并且需要牺牲一些区块链的理念，因为它依赖于中心化的角色和中介机构。而信任最小化隐私可以提供更强的隐私保障，确保用户始终掌控他们的数据，但在技术和政治层面上都更具挑战性（例如，如何在保持合规的同时实现信任最小化）。

区块链网络中的信任隐私

信任隐私方法与Web2风格的隐私相似，可以实现用户之间的隐私保护，但需要信任第三方或中介来促成这一点。这种方法的技术要求不高，因而对于那些需要一定隐私保障但又对成本敏感、交易价值较低的项目来说，是一种务实的选择。比如，Web3社交协议（如Lens网络）更注重性能和实用性，而不太关注隐私保障的严密性。

一个简单的实现方式是使用Validium架构，其中数据可用性委员会（DAC）持有当前状态，用户信任DAC运营者来保持状态的私密性并在需要时更新。例如，Solana的代币扩展使用零知识证明（ZKP）来确保支付的机密性（隐藏账户余额和交易），但允许指定一个可信的第三方拥有审计权，以确保符合监管要求。

我们认为，这种模式可以扩展当前的Web2范式，即你仅仅信任一个中介来遵守规则。在区块链中，纯粹的信任模型可以与一些额外的保障措施（经济或加密学的保障）相结合，以确保中介按照预期行事，或者至少增加中介按照预期行事的激励。

此外，还有一些混合解决方案，信任最小化的方案依赖于一个中心化的组件来提高成本效益、用户体验或性能。例如，私密零知识证明的证明过程可以外包给一个单一的证明者，或者在同态加密（FHE）网络中，中心化的中介持有解密密钥。

（我们将许可链归入可信类别，但所有其他解决方案都与无许可区块链有关。）

区块链网络中的信任最小化隐私

信任最小化方法通过避免通过受信任中介来降低单点故障的风险，从而提供更强的保障。然而，从技术角度来看，这种方法更难实现。在大多数情况下，它需要结合现代密码学解决方案和结构性改变，例如使用不同的账户结构。

现有的解决方案主要围绕特定的用例展开，例如：

• 金融：私密转账、支付和互换旨在隐藏身份、输入和/或输出（谁发送了什么，发送了多少，发送给了谁）。不同解决方案之间的权衡包括单资产与多资产保护池的选择，以及隐私程度的差异。此类的示例包括Zcash、Namada和Penumbra。
• 身份：对于任何需要将链下身份与链上身份关联或尝试将身份文件存储在链上的解决方案来说，隐私都是不可或缺的。目前，私营部门（如Proof of Passport和Holonym）以及政府越来越关注隐私保护的数字身份解决方案。
• 治理：链上私密投票的目的是隐藏谁投了什么票，并在投票结束前保持总票数的私密性，以免影响个人的投票决定。下图列出了一些具有不同特性和信任假设的示例：

• 一些现有解决方案概述（来源）

然而，许多用例依赖于共享状态，而当我们试图将信任最小化的隐私扩展到这些通用用例时，挑战变得更加艰巨。

需要注意的另一点是，尽管某些专用用例（如支付、投票、身份等）在单独使用时可能运行良好，但它们需要用户在不同用例的保护集合（信任区）之间进行切换。这种方式并不理想，因为大多数信息在进出保护集合时会被泄露。

因此，目标应该是为通用计算（所有用例，包括需要共享状态的用例）实现隐私保护，扩大保护集合，并增加细粒度的访问管理控制（表达性）。

我们如何评估不同的解决方案？

虽然最终目标明确，但实现这一目标的道路漫长。在此期间，我们需要框架来评估当前的解决方案及其所做的权衡。我们认为，权衡空间可以分为三个广泛的类别：

1. 隐私类型 - 与区块链相关的不同隐私类型

• 私有输入（消息）: 保持输入数据的隐私，如用户发送的交易数据或信息。
• 私有输出（状态变化）: 确保系统状态的变化只对授权方可见，保护交易结果的隐私。
• 私有对手方: 在交易中隐藏对手方的身份，确保交易双方的信息不被泄露。
• 用户隐私: 保护用户身份，确保用户的匿名性。
• 函数隐私: 隐藏被调用的具体函数，例如用户使用了哪种竞价逻辑，确保操作的细节不被暴露。
• 程序隐私: 一个更严格的隐私形式，不仅函数调用是私密的，用户与之交互的整个程序也是私密的。
  理想情况下，一个解决方案能够涵盖所有这些隐私维度，但通常需要在实现过程中做出一些权衡。函数隐私与程序隐私的区别在于，函数隐私可能仍然暴露了用户交互的程序，而程序隐私则完全隐藏了所有相关操作。这一类别中还包括关于匿名性（谁）与保密性（什么）的讨论。
  需要注意的是，用户可以选择性地向特定方披露部分或全部信息，但如果这些隐私特性默认不被保护，用户就失去了这种选择的权利。

2. 可编程性 - 隐私可以用于什么？

• 加密数据的计算能力: 系统是否能够在加密数据上执行计算？
• 私有程序的可组合性: 私有程序之间是否存在可组合性？私有和公共状态之间是否可以交互？这些交互有什么限制和权衡？
• 程序复杂度的限制: 系统对程序的复杂度有什么限制？例如，gas 限制、表达能力等。
  现实世界中的许多应用需要某种共享状态，而在信任最小化的环境中实现这一点非常困难。当前有大量的研究工作致力于从仅需局部状态的特定应用隐私解决方案（如支付），向具有共享状态的通用可编程隐私解决方案过渡。
  可编程性还涉及到选择性披露信息的粒度工具，例如在员工辞职时，确保他们不再拥有对公司特定或其他敏感信息的访问权限。

3. 隐私保证的强度 - 隐私的可靠性如何？

• 隐私的未来保证（前向隐私）: 我们如何确定今天私密的信息在未来仍然保密？支持这一点的保证有哪些？
• 与可信第三方或中介共享的信息: 用户需要与可信的第三方或中介共享哪些信息？中介行为符合预期的保证是什么？
• 受保护集合的大小: 受保护集合的范围有多大？（多链 > 网络（L1/L2）> 应用 > 单一资产）
• 审查风险: 系统面临的审查风险有多大？（应用层隐私 vs 基层隐私）
• 证明系统的抗量子性: 系统的证明机制是否抗量子计算？
• 证明系统是否需要可信设置: 如果需要，有多少参与者参与了设置？
• 系统是否默认隐私: 系统是否默认提供隐私保护？是否有激励措施来最大化受保护集合中的交互数量？

上述类别包括了技术问题（如选择哪种证明机制）和设计问题（如增加激励以扩大受保护集合的规模）。

这个权衡框架如何映射到帖子开头提出的四个问题？

• 可以揭示什么信息，并且在有需要时向谁揭示？ 这个问题与隐私和可编程性有关。如果所有信息默认都是公开的，那么用户在隐私方面唯一的选择就是是否参与网络。为了确保用户有选择权，必须默认保护隐私（至少是其他用户或外部观察者无法获取的隐私）。可编程性可以表现为细粒度的披露规则，即信息在何时、向谁、以何种方式揭示（以及撤销）。
• 谁有权揭示信息？ 这主要与隐私保障的强度相关。只有用户自己掌握信息披露的权力时，隐私保障最为强大（即信任最小化的隐私）。
• 为了系统的运作，必须揭示什么信息以及向谁揭示？ 这主要涉及可编程性。理想情况下，应该尽量少披露信息，同时仍能够在共享状态上进行计算、不同程序之间保持可组合性，并且能够建立新的信任关系。但在实际中（至少在当下），需要进行一定的权衡。
  从区块链之外的角度来看，零知识证明（ZKP）可能会为隐私方面带来范式转变，因为它们使我们能够在不披露过多信息的情况下证明某件事情为真。例如，在租房时，我们需要向房东证明我们有足够的收入支付房租。如今，这通常要求我们提交整个银行对账单，从而暴露大量额外信息。在未来，这种信任关系可能会基于简洁的零知识证明来建立。
• 如何保证今天是私密的信息在未来仍然保持私密？ “前向隐私”的概念主要与隐私保障的强度有关。更大的屏蔽集将有助于这一点，并使外部观察者更难提取信息。减少对中介的信任也有助于此，但这并非绝对可靠，因为即使用户完全掌控自己的数据，其密钥可能会泄露，数据可能会无意中被揭示或已揭示的数据可能被复制。这个领域目前仍相对未被探索和研究，但随着区块链网络中隐私的广泛采用，其重要性将不断增加。

总结

归根结底，问题在于谁应该控制数据的分享——用户还是中介机构。区块链试图增强个人主权，但这是一场艰难的斗争，因为控制意味着权力，而权力斗争通常是复杂且混乱的。这也涉及到监管和合规性的问题——这就是为什么去中介化或信任最小化的隐私保护将面临挑战（即使我们解决了技术障碍）。

目前，讨论主要集中在金融用例（支付、转账、交换等）的隐私问题上——部分原因是这是目前采用率最高的领域。然而，我们认为，非金融用例的重要性丝毫不亚于金融用例，甚至可能更为重要，而且这些用例并没有那么多先入为主的负担。例如，需要私密输入或状态的游戏（如扑克、战舰游戏）或希望保管好原始文件的身份解决方案，可以成为在区块链网络中普及隐私保护的强大推动力。此外，还可以在同一应用程序中为不同的交易设置不同级别的隐私，或者在满足某些条件时披露某些信息。大多数这些领域目前仍未得到充分探索。

在理想的情况下，用户可以完全自主决定什么是私密的，以及向谁披露，并且有强有力的保障措施确保被编程为私密的信息能够保持私密性。在我们隐私系列的第二部分中，我们将深入探讨实现这一目标的不同技术及其权衡。

向信任最小化、私密化、通用计算的区块链转型将是一个漫长而艰难的过程，但最终是值得的。

声明：

1. 本文转载自[equilibrium]，原文标题为[What Do We Actually Mean When We Talk About Privacy In Blockchain Networks (And Why Is It Hard To Achieve)?]，版权所有归原作者[Hannes Huitula]所有。如果对此转载有异议，请联系Gate Learn团队，他们会及时处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人立场，并不构成任何投资建议。
3. 本文翻译由Gate Learn团队完成，除非特别注明，禁止复制、分发或抄袭本文翻译内容。