本文作者：0xNovachrono；编译：Cointime Freya

作品简介:

随着Web3技术引领我们走向所有权驱动软件的新时代，一个关键问题仍然存在——隐私。用户是否愿意被随机的匿名方跟踪他们的用户数据？这样的做法是反用户的，可能会阻碍这一运动的大规模采用。数据需要是安全的，在理想的情况下，应该是任何与业务相关的人都可以访问的。然而，在实践中，由于区块链的公共性质，我们公开发布数据，使任何有互联网连接的人都能广泛访问。 这是非常不安全的。传统公司制定数据隐私政策是有原因的，为了把传统的应用程序带到这个新的互联网上，我们需要弄清楚Web3的HTTPS版本。本篇文章这是两篇文章系列中的第一篇，我们重点讨论试图将隐私带入区块链的不同方案，并指出缺失的内容、其必要性以及缺失的原因。

为什么隐私在我们的生活中至关重要？

告诉全世界你有多少钱、赚多少钱、花多少钱是不够资格的，这就是为什么如今的现金是私有的。你将无法告诉最后十个接触过你的10元<你的货币>账单的人。系统中缺乏隐私意味着缺乏安全性。在Web3的世界里，你根本就不是在和钱打交道；你正在处理各种应用程序，这些应用程序记录你在链上的产出，而这些产出又都和你联系在一起。这就像公开你的私人日记一样。

为了在开发复杂系统方面取得长期成功，在与其他网络成员协调的同时确保个人信息的私密性就变得至关重要。

深入到一个完全没有隐私的世界——区块链。在这种新模式下运作，意味着你的地址就是你的身份，你与它的每一次互动，都可以让所有人看到它所有的数据驱动的活动。

事实上，如果不加控制，公共区块链很容易就会被利用——如果用户想在网络空间的旅程中保持平静，那么隐私解决方案就必不可少。

我们过去在区块链隐私保护系统方面的发展时间表:

尽管为了在区块链系统上实现隐私的广泛采用而进行了大量的投资和研究，但所有的努力都被证明是难以实现的——是时候评估现有的框架了。这就是为什么我们对当前的解决方案进行分类分析，以以深入了解为什么它们尚未得到有效实施。

Monostatic 系统——伟大的开始：

让我们从Monostatic系统开始研究。这种类型的框架允许用户在预定义函数Ø上处理计算，以帮助他们更新系统的全局状态。由于缺乏支持任意计算的灵活性，这种原理图将被视为具有预定义和已知变量的静态系统。从本质上讲，整个系统的状态被封闭在预定义函数Ø的集合中。

Zcash是Monostatic系统的领先示例，它促进了保护隐私的比特币框架的开发。其全局状态包括以注释形式的加密承诺，这些注释是由 Zerocash 框架内提供的预定义脚本功能生成。Zk-snarks在更新该账本时验证诚实和完整性，在保持用户匿名的同时保证交易安全。

MultiStatic——尝试新事物：

接下来，我们有MultiStatic系统。这些系统支持修改全局状态更新层，允许在分类账中插入新的变量。这些框架将允许用户定义任意函数（β,δ,ζ,η...），并帮助他们在操作时保留完整的隐私。

ZEXE是2018年出炉的zerocash论文的修改扩展，是拥有一个支持私人账本之上的任意计算的系统的更好答案之一，为用户提供功能和数据隐私。ZEXE修改了zerocash论文提供的现有指令集，并根据其死亡和出生谓词对记录而不是硬币进行操作。Mina，Aleo建立了这个框架的实现。

多静态系统下的方案使用UTXO模型构建的，其中系统的全局状态以碎片化和加密的格式存储。用户永远无法与完整的应用程序状态交互，只能通过个别功能以p2p的方式与其他用户交互。用户可以在两个进程之间进行进程间调用，但前提是用户在最终函数中公开了任何状态。 用户只能与应用程序的一部分进行交互。

Sub-Socket系统——让我们闭上眼睛，别人就看不到我们了

Sub-Socket系统是与MultiStatic系统并行的基于硬件的框架，用户可以修改系统的全局状态，从而支持由不同功能组成的任意应用程序Δ = {β， Δ，ζ，η…}。这些设计非常灵活，可以支持多种虚拟机。它们可以支持基于帐户的模型，并允许用户与作为一个整体的合同互动，而不是访问一个函数来处理由MultiStatic系统提供的交互。

这种系统的全局状态层包括由系统生成的唯一密钥对保护的不同合约。用户可以通过加密他们的输入以供硬件（TEE）处理来与各个合约进行交互。用户可以通过使用自己的私钥解密系统全局状态层，以查看输出。Secret Network、Phala等都是Sub-Socket系统的各种实现。

Sub-Socket系统帮助用户以聚合格式与整个合约状态进行交互，但不能在驻留在全局状态更新层内的不同合约之间进行进程间通信，并且本质上将整个系统分割成在分类帐上运行的异质和孤立的合约。

隐私保护系统中的“State Denial”问题：

我们成功地传达了两种隐私：功能隐私和数据隐私，这是我们在构建隐私保护系统时可以使用的少数框架。我们可以为用户提供在进行状态更新时，通过MultiStatic系统隐藏数据和功能的能力。我们可以通过Monostatic系统和Sub-Socket系统为用户提供数据隐私，在系统中启动一个功能后，用户可以同时隐藏他们的输入和输出、

根据这些系统的属性，我们可以对它们进行三种类型的分类。从Monostatic系统开始，系统中全局状态的维度保持不变。用户只能对一组固定的指令进行操作，来更新系统的状态。接下来是MultiStatic系统，它允许用户通过根据特定规则集定义新函数，以及扩展框架的功能，来修改系统全局状态的维度。最后，在Sub-Socket系统中，用户在全局状态更新层中定义了多个彼此隔离的异构空间。

除了能够通过这些框架提供功能和数据隐私，而且不考虑使用的加密原语之外，我们还遇到了以下障碍：

Monostatic系统强制用户在狭窄的定义范围内操作，防止他们进行任意修改。这些限制性环境的设计主要是为了保存价值，只能满足优先考虑这个单一目标的社区以外的人。

此外，在Monostatic和MultiStatic系统中，用户不能访问系统的整个状态或任何特定的应用程序。这是由于单用户状态是以碎片化和加密的形式存储在系统中的。除了基于谓词的编程的困难之外，我们只设想在MultiStatic系统中两个不同的程序之间，进行的某种程度的函数间（进程）通信，只有当用户在目标程序中拥有一个状态时，才能与另一个函数进行交互。

除了MultiStatic系统之外，我们还无法在Sub-Socket系统中为用户提供对整个系统的全局共享状态的访问。我们能够为用户提供对其程序的共享状态的访问，但无法让用户看到同一全局状态层中的其他程序状态——最终排除了该框架内的任何跨功能调用。

我们所有分类框架的共同点是，我们无法为用户提供访问系统内定义的外国状态的权限，本质上是在我们的全球分类帐中为每个用户创建了隔离环境。这导致程序之间需要进行函数间调用，阻碍用户访问整个系统的全球状态，从而阻碍了隐私保护系统的发展。这种现象被称为“State Denial”。

悖论：

如果你想创建一个加密程序，无论是通过同态加密、基于MPC的私有合约，还是利用任何框架的其他技术，你都要处理这样一个事实：一旦你在系统中设置了任何变量：私有，其他网络成员将被禁止与你的私有数据交互。换句话说，你的私有数据就类似于全局状态更新层中的一座私有岛屿，它只将其访问权限本地化并授权给数据所有者，使得其他网络参与者对系统的全局内容一无所知，直到达成一致。

每一个私有应用程序，无论是建立在任何系统上，都为用户提供了进行函数内调用的能力，允许用户在整个系统中彼此交互，且拥有在多个程序之间处理函数间调用的能力，在这些程序中，其中涉及目标程序的外来调用不能访问状态。

上述属性对于使系统私有化至关重要，但这是零知识系统工作方式的基础。

根据经验，当您使将应用程序状态设置为私有时（对网络隐藏），您可以使该状态仅对该应用程序的本地用户可访问，并防止任何外部参与者访问您的应用程序状态。这是我们所知的所有隐私保护系统的普遍条件，被称为“State Denial”。

我们了解了上述框架提供的两种类型的隐私：功能隐私和数据隐私。然而，还有一种被称为可组合隐私的新型隐私，我们可以为用户提供对系统的全局共享状态的访问，同时仍然允许他们进行私有状态转换。从这种理想框架衍生出来的隐私被称为可组合隐私。

在这三个框架中，我们只对现有的系统进行了分类：MultiStatic系统允许某种程度上的函数间（进程）通信。MultiStatic系统，如ZEXE、zkVM、Dialeaktos等，利用一个基于UTXO的框架，不支持任何形式的系统范围的状态聚合。相反，用户只能通过选定的功能进行交互，即使是在他们已经在程序中注册了应用状态的情况下也是如此。由于所有用户数据都是加密和个性化的，因此不能在这种范式下构建诸如AMMs之类的应用程序，因为此类操作需要访问整个生态系统的状态——这是Multistatic框架所不支持的，因此在此框架下会出现更多关注peer2peer的应用程序。

公共区块链上的智能合约使用户能够与多个程序以及原子后调用进行交叉交互，从而提供比传统数据库架构更大的灵活性。使用分布式账本系统在运营商的各个节点上安全地记录交易。这些操作员可以查看网络中接受的每个合同更改的最新全局状态。

如果我们在全局状态更新层中将系统状态的一部分设置为私有，那么整个多维访问流和发布函数间调用的能力将变得不切实际。因为对数据的访问将被撤销（即“State Denial”的问题），或者，如果我们想让系统具有交叉互操作的能力，那么这就有点自相矛盾。即使在我们的Sub-Socket系统中，我们可以通过聚合的方式为用户提供对整个应用程序状态的访问，我们仍然需要在相同的全局状态层中允许用户在线访问其他应用程序状态。如果我们使用上述的任何私有框架，就很难在一个无权限且中心化的智能合约支持的基于帐户的系统上，建立一个为用户提供保护隐私的状态转换的应用生态系统，就变得很困难。

我们必须构建一个原理图，并定义允许可组合隐私存在的框架。在一个系统中，某人可以以隐私保护的方式访问终端应用程序，应用程序可以与其他网络成员共享系统的全局状态。这个属性是当前以太坊和类似以太坊的链上应用程序的基础。在此框架下的应用程序可以执行函数间调用，帮助我们在网络中扩展价值流，而不是将其视为孤立的片段。

然而，回顾一下“State Denial”问题，为加密应用程序状态而构建的私有应用程序不能与另一个应用程序共享其状态，也不能在彼此之间最大限度地进行互操作或进行函数间调用。 从而阻碍了私有生态系统的实质性发展，且阻碍了用户体验，因此我们现阶段面临的悖论可以表述为：

“如果我们想让应用程序状态私有化，我们就不能与网络中的其他成员共享系统的细节，但如果我们想让应用程序可组合，我们就无法获得对应用程序状态的访问权限。

为了实现我们的理想环境，我们必须弄清楚如何将可组合隐私付诸实践。但我们如何创造一个繁荣的隐私环境呢？我们如何在公共系统所展示的相同的可用性和去中心化特征下，且在不需要隔离应用程序状态的情况下，构建一个保护隐私和通用的智能合约交互的框架？

“State Denial”是一个严重的问题，但Silent Protocol的经济型零知识执行环境（EZEE）以非常简单的方式解决了上述所有问题。这是一个允许可组合隐私的新颖框架，我们渴望尽快分享有关其背景和构成的更多详细信息！下一篇文章揭晓一切，敬请期待！