转发原文标题《How can we make the use of web2 data in web3 actually private and verifiable?》

许多人认为 Web3 是新互联网，并用“读取、写如、拥有”这一短语来定义它。“读取”和“写入”部分很清楚，但谈到“拥有”数据时，今天我们几乎什么都不拥有。

用户数据常常被公司窃取，并被他们利用；我们在互联网上并不真正拥有任何东西。

然而，我们不能仅仅转向一个只有 Web3 而什么也不共享的世界。不，我们仍然需要共享，但只共享必要的部分。

作为一个对申请护照不熟悉的人，我被困在申请电子签证、提交无休止的个人信息以证明我符合特定签证条件的过程中。我总是会问自己：

• 为什么我必须提供完整的银行账单，而他们只需要确认特定的收入水平？

• 为什么我必须提供具体的酒店预订，而不是仅需证明我在这个国家预订了酒店？

• 为什么在他们只需验证我在当前国家的永久居留地时，我必须提交完整的护照信息？

这里有两个主要问题：服务商知道的信息远超过他们需要的，而且你提供的数据并不是私密的。但这与加密货币中的安全性和隐私性有何关系呢？

1. Web3 离不开 Web2 数据

正如大多数人所知，智能合约本身并不知道 BTC、ETH、SOL 或任何其他资产的价格。这个任务由预言机（Oracles）承担，预言机不断地将外部世界的公开数据传输到智能合约中。

在以太坊生态中，这个角色几乎被 @chainlink 的预言机网络所垄断，以确保我们不会依赖单一节点。所以，实际上我们确实需要 Web2 数据来支持更多的用例，而不仅仅是知道某些资产的价格。

然而，这仅适用于公开数据。如果我想安全地连接我的银行账户或 Telegram 账户，并分享一些私密信息，而这些信息并非公开的，而是属于我的私有数据该怎么办呢？

首先想到的是：我们如何将这些数据引入区块链，并提供证明以确保私密数据的安全？

不幸的是，情况并非如此，因为服务器不会签署它们发送的响应，因此你无法在智能合约中可靠地验证类似的信息。

保障计算机网络通信的协议被称为 TLS（传输层安全协议）。即使你没有听说过它，你每天都在使用它。例如，当你阅读这篇文章时，你会看到浏览器地址栏中的 “https://” 。

如果你尝试使用 “http://” 连接到网站（没有“s”），浏览器会警告你连接不安全。链接中的“s”代表 TLS，它确保了你的连接安全，保障隐私，并防止任何人窃取你传输的数据。

2. 连接已经安全了，难道我们不能直接在 web3 中传输并使用它吗？

正如我之前提到的，我们面临着可验证性的问题：服务器不会签署它们发送的响应，因此我们无法真正验证数据。

即使数据源同意分享其数据，标准的 TLS 协议也无法向其他方证明其真实性。仅仅传递响应是不够的：客户端很容易本地篡改数据，分享这些响应会完全暴露它们，进而威胁到用户隐私。

解决可验证性问题的一种方法是增强版的 TLS，称为 zkTLS。

zkTLS 的工作机制与 TLS 相似，但稍有不同，具体流程如下：

• 你通过安全的 TLS 连接访问一个网站并发送所需的请求。

• zkTLS 生成一个 zk 证明来验证数据，同时只揭示用户想要证明的具体细节，保持其他内容的私密性。

• 生成的 zk 证明随后被其他应用用来确认和验证所提供的信息是否正确。

当我提到 zkTLS 时，我指的是利用 zkTLS 技术的项目，但关于数据可验证性，有多种不同的解决方案，具体包括：

1. TEE（受信执行环境）
2. MPC（多方计算）
3. Proxy（代理）

有趣的是，每种方法都引入了独特的用例。那么，它们有何不同呢？

3. 为什么 zkTLS 没有单一标准？它们有何不同？

zkTLS 不是一项单一技术，因为可以从多个角度验证私有 Web 数据而不暴露它，每个角度都有自己的权衡。核心思想是用证明来扩展 TLS，但如何生成和验证这些证明取决于底层机制。

正如我之前提到的，三种主要方法是使用 TEE-TLS、MPC-TLS 或 Proxy-TLS。

TEE 依靠专门的硬件（例如 Intel SGX 或 AWS Nitro Enclaves）来创建一个安全的“黑匣子”，可以在其中处理数据并生成证明。硬件确保数据保密且计算防篡改。

在基于 TEE 的 zkTLS 设置中，TEE 运行协议，证明 TLS 会话的执行和内容。验证者是 TEE 本身，因此信任取决于 TEE 的制造商及其对攻击的抵抗力。这种方法效率高，计算和网络开销低。

然而，它有一个重大缺陷：你必须信任硬件制造商，TEE 中的漏洞（如旁路攻击）可能会破坏整个系统。

Proxy-TLS 和 MPC-TLS 因其用例范围广泛而成为最广泛采用的方法。建立在 @eigenlayer 上的项目如 @OpacityNetwork 和 @reclaimprotocol，利用这些模型来确保数据安全和隐私以及额外的经济安全。

让我们看看这些解决方案的安全性、zkTLS 协议支持哪些用例以及目前已经推出的功能。

4. MPC-TLS 和 Opacity Network 有何特别之处？

在 TLS 握手过程中（客户端和服务器通过共享加密密钥来达成安全通信的协议），网站的角色保持不变，但浏览器的处理方式有所不同。

它不生成自己的密钥，而是使用节点网络通过 MPC 创建多方密钥。该密钥为浏览器执行握手，确保没有任何一个实体知道共享密钥。

加密和解密需要所有节点和浏览器之间的合作，在数据到达或离开网站之前，每个节点都按顺序添加或删除自己的加密部分。 MPC-TLS 提供强大的安全性并且可以分布式，因此没有一个团体拥有所有权力。

Opacity Network 通过添加保障措施来最大程度地减少信任问题，增强了经典 @tlsnotary 框架。它采用多种安全措施，例如：

1. web2 账户 ID 的链上验证

2. 提交方案

3. 揭示方案

4. 随机 MPC 网络采样

5. 可验证的尝试日志

帐户 ID 在 web2 系统中是静态的，允许委员会提供证明，十个不同的节点必须确认所有权。这会将帐户链接到一个唯一的钱包，从而防止重复尝试使用不同的钱包来查找共谋节点。

您可查看下图，详细了解 Opacity 的工作原理：

Opacity 节点在 TEE 内运行，如果 TEE 是安全的，那么串通几乎是不可能的。除了 TEE 之外，Opacity 还使用 Eigenlayer 来利用 AVS，要求节再质押 32 stETH，对不当行为立即进行罚没，避免了冷却期带来的延迟。

可以看到，Opacity 同时使用了 MPC 和 TEE，但由于 MPC 用于 zkTLS，而 TEE 主要用于节点安全，因此仍称为 MPC-TLS。

然而，如果 TEE 失败，节点可能会参与 MPC 内的串通。这就是为什么需要额外的经济安全层来防止这种行为的原因之一。

这也是 Opacity 正在开发举报机制的原因，在该机制中，能够证明公证人行为不当的用户将获得公证人股份所受处罚的一部分。

由于其集成简单、安全，且能保障隐私，Opacity 吸引了各种协议将其集成到消费者、DeFi 和 AI 代理领域的产品中。

来自 @earnos_io 的团队自正在开发一个平台，品牌可奖励参与或完成任务的用户。 EarnOS 使用 Opacity 的技术通过流行的应用程序证明特征，而无需透露个人信息，让品牌瞄准受众，同时用户保护隐私并获得奖励。

Opacity 也被集成到 @daylightenergy_ 协议，开发一个去中心化的电力公用事业网络，用户可通过为清洁能源解决方案做出贡献而获得奖励。借助 Opacity，用户无需专门的硬件即可在链上证明能源设备的所有权。

Opacity 甚至可以与人工智能代理集成，为当前面临重大挑战的领域带来更多的可验证性和透明度。 zkTLS 最近被集成到 @elizaOS，允许可验证的人工智能交互而不会破坏隐私。

然而，TEE-TLS 和 MPC-TLS 只是 zkTLS 的两种变体，还有第三种称为 Proxy-TLS，Reclaim Network 是该模型最著名的代表。那么，它在技术方面与其他两种变体有何不同，以及 Proxy-TLS 可以启用哪些用例？

5. Proxy-TLS 和 Reclaim Protocol 有何特别之处？

HTTPS 代理在互联网上很常见，可转发加密流量而不访问其内容。在 zkTLS 代理模型中，它的工作原理几乎相同，只是略有增加：

• 浏览器通过代理向网站发送请求，代理还处理网站的响应。

• 代理查看所有加密交换并证明其真实性，注意每个交换是请求还是响应。

• 然后，浏览器生成一个 zk 证明，表明它可使用共享密钥加密该数据而不泄露密钥，并显示结果。

• 这是有效的，因为几乎不可能创建将数据转换为任何有意义的内容的假密钥，因此只需显示您可以解密它就足够了。

泄露密钥会危及之前的所有消息，包括用户名和密码等敏感数据。Proxy-TLS 速度相当快、价格实惠，并且可以很好地处理大数据量，因此非常适合高吞吐量设置。

大多数服务器不会根据不同的 IP 地址来限制访问，因此该方法的适用范围相当广泛。

Reclaim Protocol 使用 Proxy-TLS 进行高效的数据验证，并使用代理绕过 Web2 防火墙，防止大规模代理阻塞。

它的工作原理如下：

这里的主要问题是共谋：如果用户和证明者共谋，他们基本上可以签署任何东西并进行恶意行为。为了缓解这种情况，Reclaim 包含了一部分验证者，这些验证者被选择来引入随机性并阻止此类漏洞。

Reclaim 使用 Eigen 的 AVS 将验证去中心化。EigenLayer 操作员可充当证明者，但他们需要部署自己的 AVS 来指定其服务的证明逻辑。

Reclaim 是一个支持独特用例的平台，例如为交通应用程序导入拼车数据、为区块链经济桥接链外数据、使用国民身份证数据验证身份、通过开发人员工具创建自定义数据解决方案等等。

Reclaim 生态系统拥有 20 多个项目，但我想重点介绍其中 4 个项目，涉及货币市场、数字身份、消费者和招聘领域。

@3janexyz 是 Base 上第一个基于信用的货币市场，通过使用链上和链下财务数据评估加密用户的信誉和未来现金流，为他们提供有担保的信用额度。

3Jane 使用 Reclaim 的代理模型来验证来自 VantageScore、Cred、Coinbase 和 Plaid 的信用数据，确保这些数据的隐私。

另一个使用 zkTLS 与信用评分相关的例子是 @zkme 的功能——zkCreditScore。它利用 Reclaim 协议通过 zkTLS 安全地获取你的美国信用评分。这样，zkMe 可以检查用户的信用评分，并创建独特的灵魂绑定代币（SBTs）来存储这些数据。

除了信用评分之外，还有其他用途吗？当然有。

我们可以以 @zkp2p 为例，它是一个消费品市场，利用 Reclaim 协议验证用户的 Ticketmaster 数据以及支付信息。

与此同时，@bondexapp，作为加密领域最受欢迎的招聘平台之一，也使用 Reclaim 来获取用户的工作证明，确保数据的真实性、隐私性和可验证性。

从 zkTLS 的应用场景来看，能够在链上验证 TLS 记录已经解锁了许多新的功能，让用户可以控制自己的数据，而不需要依赖大企业的许可。

更重要的是，zkTLS 旨在确保你的个人数据不会被用来对付你。那么，未来将会走向何方呢？

6. zkTLS 会长期存在吗？

尽管仍有一些工作要做，但不同的 zkTLS 协议已经开始引入新的用例，将权力重新分配给用户。

@Tim_Roughgarden 在 a16z 加密播客中强调，zk 证明（zk proofs）早在 1985 年就提出，但直到区块链应用的兴起，才真正获得了广泛关注，这要感谢数百位开发者为减少证明大小和成本而做出的不断努力。

如今，区块链行业的贡献正在被应用到加密之外的其他领域。

我预计 zkTLS 会经历类似的历程，首先在 Web3 中实现，然后扩展到其他领域。正如我之前所说，现在我们虽然可以“读取”和“写入”，但在数据保护方面几乎没有保障，甚至连自己的数据都无法“真正拥有”。

免责声明：

1. 本文转载自 [Pavel Paramonov]。所有版权归原作者所有 [Pavel Paramonov]。若对本次转载有异议，请联系 Gate Learn 团队，他们会及时处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。