原文地址：https://eng-blog.o1labs.org/posts/ssn-blog/

作者：Vanishree Rao

翻译：MINA Holder（翻译于原文）

这是 Web3 可以解决的 Web2 中数十亿美元问题的一个很好的例子。

现状是，诸如国民身份证号（在美国是 SSN，在英国是 NIN）等个人敏感信息在各个机构中传播，使这些机构成为黑客的引诱目标。这些机构花费数十亿美元——充其量只是微弱地——保护这些数据宝藏。一旦他们被黑客入侵，他们就会花费另一笔钱来安抚客户，支付监管罚款并在品牌形象的巨大创伤上使用营销创可贴。

Web3 有解决这个问题的方法。这个想法是避免在各个机构之间共享此类敏感信息，而是共享您的敏感信息的证明，而不使用零知识证明 (ZKPs) 共享信息本身。请继续阅读以了解它是如何工作的。

在我们继续之前，让我们回顾一下 ZKPs 的力量。它们提供两种权力——隐私和简洁。在我们的案例中，我们将主要使用隐私权。具体来说，ZKPs 允许我们证明我们知道某事而不透露它。这里的想法是证明机构需要知道什么，同时保持敏感信息的私密性。

为了进一步描述，让我们考虑以下涉及银行的示例。对于涉及银行的几乎每一项任务，都需要与银行分享他们的国民身份证号码。假设您正试图从银行获得贷款。在 Web2 世界中，银行需要您的国民身份证号码来与征信机构核实您的信誉。需要注意的一个重要方面是，您不能简单地从信用局获得您的信用评分（许多其他国家/地区存在的信用度衡量标准）并创建一些收据证明。这是因为 Web2，特别是 TLS 协议的设计方式；服务器不对 HTTP 响应进行签名，因此第三方无法验证数据的完整性/出处。

让我们看看我们如何避免在 Web3 世界中与银行共享国民身份证号码。

Mina 上的 zkApps 平台（即将启用）的一个特殊功能称为 \emph{zkOracles}，旨在解决这个问题。在运行示例中，银行将部署一个 zkOracles 智能合约，该合约可以验证客户发送的数据（通过验证 ZKPs）。客户端按如下方式生成 ZKP。

回想一下，主要要求是，当客户端从服务器获取数据时，我们需要以某种方式对该数据进行身份验证，以便 zkOracle 可以对其进行验证。为此，将有一个或多个“公证人”来监督客户端和服务器之间的通信。但是，公证人不会了解有关客户端和服务器之间交换的数据的任何信息。（事实上​​，人们甚至可以选择对公证人隐藏服务器身份。）然后公证人将签署（即，公证）成绩单。然后，客户端可以创建一个 ZKP，证明加密数据来自正确的服务器（通过验证 TLS 协议中使用的证书）、关于加密数据的一些谓词（在脚本中）以及加密数据经过公证。

回到运行示例，一旦银行部署了智能合约，客户就可以通过 HTTP 连接从信用局获取她的信用评分。然后，在不透露敏感信息的情况下，客户可以证明她从该局获得了 $x$ 的信用评分。x从局。

如上所述，使用 zkOracles，人们可以在不向各种实体透露敏感信息的情况下执行任务，从而防止由于大型数据库黑客攻击而导致的身份盗窃。

如果您对此感兴趣，请关注O(1) Labs 博客和Mina 协议时事通讯，以免错过任何更新。

zkOracles 将在未来几个月内作为Mina zkApp CLI的一部分提供。您可以通过阅读zkApps 文档来开始熟悉自己的介绍，并在 Mina 的 Discord 上加入 #zkapps-developers 的讨论！

原文地址：https://eng-blog.o1labs.org/posts/ssn-blog/

作者：Vanishree Rao

翻译：MINA Holder（翻译于原文）

这是 Web3 可以解决的 Web2 中数十亿美元问题的一个很好的例子。

现状是，诸如国民身份证号（在美国是 SSN，在英国是 NIN）等个人敏感信息在各个机构中传播，使这些机构成为黑客的引诱目标。这些机构花费数十亿美元——充其量只是微弱地——保护这些数据宝藏。一旦他们被黑客入侵，他们就会花费另一笔钱来安抚客户，支付监管罚款并在品牌形象的巨大创伤上使用营销创可贴。

Web3 有解决这个问题的方法。这个想法是避免在各个机构之间共享此类敏感信息，而是共享您的敏感信息的证明，而不使用零知识证明 (ZKPs) 共享信息本身。请继续阅读以了解它是如何工作的。

在我们继续之前，让我们回顾一下 ZKPs 的力量。它们提供两种权力——隐私和简洁。在我们的案例中，我们将主要使用隐私权。具体来说，ZKPs 允许我们证明我们知道某事而不透露它。这里的想法是证明机构需要知道什么，同时保持敏感信息的私密性。

为了进一步描述，让我们考虑以下涉及银行的示例。对于涉及银行的几乎每一项任务，都需要与银行分享他们的国民身份证号码。假设您正试图从银行获得贷款。在 Web2 世界中，银行需要您的国民身份证号码来与征信机构核实您的信誉。需要注意的一个重要方面是，您不能简单地从信用局获得您的信用评分（许多其他国家/地区存在的信用度衡量标准）并创建一些收据证明。这是因为 Web2，特别是 TLS 协议的设计方式；服务器不对 HTTP 响应进行签名，因此第三方无法验证数据的完整性/出处。

让我们看看我们如何避免在 Web3 世界中与银行共享国民身份证号码。

Mina 上的 zkApps 平台（即将启用）的一个特殊功能称为 \emph{zkOracles}，旨在解决这个问题。在运行示例中，银行将部署一个 zkOracles 智能合约，该合约可以验证客户发送的数据（通过验证 ZKPs）。客户端按如下方式生成 ZKP。

回想一下，主要要求是，当客户端从服务器获取数据时，我们需要以某种方式对该数据进行身份验证，以便 zkOracle 可以对其进行验证。为此，将有一个或多个“公证人”来监督客户端和服务器之间的通信。但是，公证人不会了解有关客户端和服务器之间交换的数据的任何信息。（事实上​​，人们甚至可以选择对公证人隐藏服务器身份。）然后公证人将签署（即，公证）成绩单。然后，客户端可以创建一个 ZKP，证明加密数据来自正确的服务器（通过验证 TLS 协议中使用的证书）、关于加密数据的一些谓词（在脚本中）以及加密数据经过公证。

回到运行示例，一旦银行部署了智能合约，客户就可以通过 HTTP 连接从信用局获取她的信用评分。然后，在不透露敏感信息的情况下，客户可以证明她从该局获得了 $x$ 的信用评分。x从局。

如上所述，使用 zkOracles，人们可以在不向各种实体透露敏感信息的情况下执行任务，从而防止由于大型数据库黑客攻击而导致的身份盗窃。

如果您对此感兴趣，请关注O(1) Labs 博客和Mina 协议时事通讯，以免错过任何更新。

zkOracles 将在未来几个月内作为Mina zkApp CLI的一部分提供。您可以通过阅读zkApps 文档来开始熟悉自己的介绍，并在 Mina 的 Discord 上加入 #zkapps-developers 的讨论！