打破时空小说的 zk 证明

Space and Time 推出了 Proof of SQL，这是一种针对 SQL 操作的新颖的 zk-proof，这是该项目任期内最受期待的时刻之一。该协议现已提供 alpha 版本，已交付给第一批项目，这些项目将使用该协议将可验证的查询连接到其智能合约。对于 Space and Time 的核心团队、社区和客户来说，此次发布是一个激动人心的时刻，也是我们创造的“验证一切”未来的一个巨大飞跃。

如果您一直关注 Space and Time 或 Web3 新闻周期，您可能听说过 SQL 证明。但除非您精通 zk 或者确实做了功课，否则您可能仍然想知道它到底是什么。 SQL 证明是一个 zk-SNARK，它以加密方式证明在空间和时间中运行的查询是准确的，并且查询和底层数据都是可验证的防篡改。如果这句话对您来说非常直观，您可以在此处了解有关如何开始使用 SQL 证明进行构建的更多信息。如果没有，请跟我一起，我们将解决它。

在解释一项复杂技术时，我喜欢从谈论它解决的问题开始。如果您尚未了解篡改查询的含义，那么防篡改查询的概念就没有意义。如果您还没有意识到系统不具备可验证性的后果，那么可验证性就没有多大意义。 SQL 证明不仅有可能从根本上改变 Web3，而且有可能从根本上改变世界商业和经济的整个数据基础。但是……怎么办？

为了回答这个问题，让我们回顾一下数据篡改的悠久且造成经济损失的历史。数据篡改是指有人操纵、更改或删除数据库中存储的信息。在许多情况下，数据篡改是由外部不良行为者（即：黑客）执行的。随着数据库在每个政府、行业和组织中变得无处不在，黑客攻击及其对企业造成的威胁使得价值2 万亿美元的网络安全产业得以蓬勃发展。公司比以往任何时候都更加投资于工具来保护其数据免受外部威胁，例如数据库内加密、基于角色的访问控制和多因素身份验证。

但恶意的外部行为者并不是公司唯一需要担心的事情。即使采取了最严格的安全措施，数据仍然容易受到可以说更大的威胁：内部人为错误。事实上，估计62% 的数据篡改事件是由有权访问数据的用户引起的。恶意、疏忽和受损的用户对组织的安全、生产力和声誉构成巨大（且代价高昂）的威胁。据估计，一次内部来源篡改数据的事件平均造成1,538 万美元的损失，这还不包括消费者信任度下降导致的收入损失。

就在今年，摩根大通因错误删除超过 470 万条电子邮件记录而被 SEC罚款400 万美元，此前该公司在 2021 年因未能保存其他通信记录而支付了 1.25 亿美元的罚款。该公司将责任归咎于其聘请来处理电子邮件数据存储的归档供应商，其中许多电子邮件是在 SEC 调查中通过传票寻求的。

今年 2 月，一名员工意外删除了处理速率限制的内部服务中的数据后，Twitter 经历了一次重大的站点范围内的停机。结果，大量用户无法发推或转发，而是收到一条错误消息，称他们已达到每日限额。

2021 年 4 月，达拉斯市解雇了一名 IT 员工，该员工鲁莽删除了达拉斯警方的20.68 TB数据，此举导致该市损失 50 万美元。这名接受过培训并有权访问数据的员工承认，他在没有检查这些表是否已备份的情况下就删除了这些表。该事件导致在大约 17,500 起刑事案件中作为证据收集的超过 870 万份档案丢失。仅 3TB 的丢失数据得以恢复。

随着网络安全行业的不断进步，有很多方法可以确保数据不被外部参与者操纵。但这些安全措施到哪里结束呢？例如，公司如何确保授权的数据库管理员不会犯下导致其损失数百万美元的错误？

好吧，这就是 SQL 证明的用武之地。 SQL 证明旨在保证两件事：在查询时，您获取的数据是正确的，并且自摄取以来没有被操纵过；您获得的查询结果是该数据的精确 SQL 计算。尽管此设计仅提供单个时间点的数据状态证明，但可以轻松地利用它来创建数据沿袭：始终数据状态的证明。您所需要做的就是按照您想要验证数据的频率设置定期运行状况检查查询 - 每隔几天、每隔几个小时，甚至每隔几秒。这将创建一个防篡改的血统，确保您的数据始终可追溯。

借助 SQL 证明，您不仅可以在篡改事件发生后立即捕获它，还可以轻松地将数据恢复到篡改前的状态。如果 DBA 不小心删除了一些表，公司就会对之前的数据进行防篡改审计跟踪。 SQL 证明允许数据库本质上充当防篡改账本，就像区块链一样，但具有业务运营所需的存储、计算和 SQL 接口。

Web3 中有一个完全独立的问题：智能合约无法提出数据驱动的问题。为了理解其中的原因，我们来讨论一下数据存储和计算在 Web3 堆栈中的位置。

区块链本质上只是一个包含单个不可变数据表的数据库。每次创建新交易时，数据都会添加到表中并永久存储在其中。如果区块链是链上存储，那么智能合约就是链上计算：一段旨在对区块链数据执行非常基本的 if/then 逻辑的代码。 “如果 X 发生，则交易 Y。”这对于简单的链上价值交换非常有效，但是对于需要更复杂计算的东西（例如期权交易）呢？就其本身而言，智能合约甚至无法提出一个简单的问题，例如“拥有该集合中的两个 NFT 的所有钱包是什么？”为了让智能合约“更智能”，你必须将它们连接到链下存储和计算；你必须给他们一种提问的方式。

SQL（代表结构化查询语言）是世界上提出问题的编程语言。这就是从微软到麦当劳的每个企业如何对数据进行计算——他们如何提出诸如“该产品上季度产生的总收入是多少？”之类的问题。他们都使用一种通用工具来完成此操作：SQL 数据库。

企业利用数据库的方式与 dapp 利用区块链的方式类似：存储、管理和检索数据。但与区块链不同的是，数据库非常高效，可以处理构建业务逻辑所需的更复杂的计算：确定系统内如何处理数据的规则。另一方面，数据仓库更加强大：它们是专门为处理分析而构建的企业级数据库。数据仓库为企业提供了一种从数据中收集见解的方法，支持趋势分析、报告和决策等任务。事务数据库和分析数据仓库都是企业数据管理堆栈的关键组成部分，并提供必要的存储和计算来补充区块链的存储和计算，并允许智能合约提出复杂的问题。

不幸的是，您不能将任何旧数据库或数据仓库（例如 PostgreSQL 或 Snowflake）连接到智能合约。其一，数据库没有预加载索引的区块链数据，智能合约必须能够知道链上发生了什么。更重要的是，链下数据库本身不会写回链，因此没有内置方法可以将您提出的问题的答案连接到智能合约。也许最重要的是，今天的数据库都需要一件与区块链根本不兼容的东西：信任。

去信任化是区块链技术的基石，也是区别于传统系统的关键因素。 “不可信”一词并不意味着区块链不可信；而是意味着区块链不值得信任。相反，它意味着用户不需要信任中央机构或中介来验证和执行交易。去信任性确保智能合约可以完全确定地执行其预定义的规则和条件，而无需外部各方的干扰或操纵。这对于自动化价值驱动流程（例如金融交易）至关重要，其中任何偏离预期行为的行为都可能产生严重后果。通过在去信任的环境中运行，智能合约保证了一致和透明的结果。

相比之下，传统数据库和数据仓库要求用户信任监督和管理系统的中央机构。这些集中式系统容易受到潜在的篡改、欺诈以及与单点故障相关的风险。将此类系统连接到智能合约会损害区块链技术的零信任模型。

看似显而易见的答案是去中心化数据库。去中心化数据库，例如 Space and Time 的去中心化 HTAP 数据仓库，将 SQL 数据库的高效计算能力引入区块链堆栈，而不会引入集中式、需要信任的故障点。在去中心化数据库中，数据分布在节点网络中，每个节点负责一部分数据。从表面上看，它似乎是对智能合约有限存储和计算的完美补充，Web3 领域的许多公司正在为此构建。

但是，除非数据和计算分布在足够多的节点上，以便有效的共识算法保证其完整性，否则信任仍然是一个因素。如果您的数据由单个节点操作员甚至少数节点操作员管理，您仍然需要相信操作员没有操纵任何内容。共识对于像以太坊这样的网络来说效果很好，因为交易会在数千个节点上复制，但随着节点数量的减少，它的效率也会降低。我们在区块链网络中看到的这种极其冗余的复制首先就是它们存储和计算如此有限的原因。所以你会怎么做？如何构建一个高效的去中心化数据库，以完全不信任的方式向智能合约提供查询结果？为此，您需要零知识证明。

SQL 证明是一种 zk 证明，可提供加密保证，确保您的数据和查询结果没有被运行数据库集群的节点操作员操纵。与依赖多个节点就数据有效性达成共识的共识不同，零知识证明允许一方证明陈述的正确性，而无需透露任何其他信息。对于 SQL 证明，它可以确保您正在查询的数据是正确的，并且自摄取以来没有被篡改，并且您收到的查询结果是该数据的准确 SQL 计算。

需要 SQL 证明来保证去中心化数据网络的去信任性，而不需要不必要的节点复制或依赖共识。这使得智能合约能够提出复杂的、数据驱动的问题并获得可信的答案，从而扩展其潜在的应用程序和功能。借助 SQL 证明，您可以实现 SQL 数据库的效率以及区块链的安全性和防篡改血统。这项技术让企业和 dapp 能够自信地利用链下存储和计算来补充智能合约的有限容量，为 Web3 应用释放新的可能性，让智能合约变得“更智能”。

现在我们已经解决了 SQL 证明解决的两个主要问题，我们可以进一步深入研究它的工作原理。我们知道 SQL 证明保证以下内容：

1. 在数据被摄取和查询之间，数据没有被操纵。

2. 您收到的查询结果是对存储数据的准确计算。

3. 查询结果本身在返回给您之前没有被篡改。

但让我们看看如何做。请记住，我们只会按照普通人（阅读：非密码学家）的需要深入了解幕后发生的事情。如需更深入的了解，请查看由 Space and Time 联合创始人、研究主管兼协议创建者 Jay White 撰写的Proof of SQL 文档。

下图显示了高级 SQL 架构的证明：

Zk 证明是一种协议，其中不受信任的证明者让验证者相信某个陈述是真实的，而无需共享任何附加信息。与任何 zk-proof 架构一样，Proof of SQL 由两个组件组成：证明者和验证者。这些组件的名称很好，并且功能与听起来完全一样：证明者生成证明，验证者对其进行验证。换句话说，将证明者视为提出主张的人，将验证者视为检查该主张是否属实的人。

在《空间与时间》中，当您使用 SQL 证明运行查询时，数据仓库（存储数据的位置）充当证明者。它生成一个证明，表明查询结果是准确的并且未被篡改。该证明是使用复杂的加密算法生成的，这需要大量的计算能力。幸运的是，数据仓库基于 NVIDIA GPU 构建，GPU 专为并行处理（相对于顺序处理）而设计，因此对于此类计算来说比 CPU 快得多。这意味着即使计算量很大，也可以相对快速地生成证明。而且由于该协议不要求证明者是不可信的（仅要求验证者），因此每个查询只需执行一次。

验证者的工作是检查证明并确保其正确。验证在计算上足够轻量，可以通过空间和时间验证器层、去中心化的预言机网络或智能合约冗余地完成，所有这些都确保了协议的去信任性。 Proof of SQL 团队正在构建轻量级验证，最终甚至可以通过运行客户端库的 iPhone 等设备来执行。

让我们一步一步地过一遍防篡改查询的过程。

当数据被摄取到空间和时间时，无论是我们从主要区块链索引的数据，还是从游戏、应用程序或其他数据库加载的数据，它首先都会通过验证器层进行路由。验证器捕获数据的承诺（我们称之为“指纹”）并将其存储起来以供以后使用。 （注：我之前提到过，验证也可以通过智能合约来完成。这是因为，与一次可能有几 GB 的原始数据不同，指纹很小，并且可以以经济实惠的方式存储在链上） 。接下来，验证器将原始数据发送到存储它的数据仓库。

当您通过 API、JDBC 驱动程序或 Space and Time Studio 发送查询请求时，验证器会将其路由到数据仓库。 （验证器还负责确定查询是事务性的还是分析性的，并将其路由到适当的 OLTP 或 OLAP 引擎，这非常简洁，但您可以在此处阅读更多相关信息）。

数据仓库解析查询，计算正确的结果，并生成加密证明，证明在计算查询时没有任何内容被篡改。然后它将查询结果和证明发送回验证者。

然后验证者检查证据、查询结果和存储的数字指纹，以确认数据在摄取时间和查询时间之间没有更改。瞧！您已经获得了防篡改的查询结果。

希望此时您对 SQL Proof 是什么、它如何工作以及它解决什么问题有一个全面的（尽管是高层次的）理解，这应该为您提供更好的基础上下文来理解它的一些用例。我们将介绍其中的两个。

让我们回到去中心化期权交易的例子。在这篇博文的前面，您读过以下内容：

“[智能合约]对于简单的链上价值交换非常有效，但是对于需要更复杂计算的东西（例如期权交易）又如何呢？就其本身而言，智能合约甚至无法提出一个简单的问题，例如“拥有该集合中的两个 NFT 的所有钱包是什么？”为了让智能合约“更智能”，你必须将它们连接到链下存储和计算；你必须给他们一种提问的方式。”

现在您知道 SQL 证明是缺失的部分，它允许智能合约询问和回答有关其自己链上的数据、其他链上的数据的数据驱动的问题（在此处阅读有关空间和时间区块链索引服务的更多信息），以及从任何链外源加载的数据。这使得 SQL 证明特别适合数据驱动的 DeFi 协议，例如去中心化期权交易平台。

期权是一种金融工具，赋予交易者在特定时间范围内以预定价格购买或出售标的资产（例如加密货币）的权利。在 Web3 中，期权交易通过智能合约实现自动化。 SQL 证明允许这些智能合约实时查询定价信息，并保证他们获得的信息准确且未被操纵。

计算期权价格的计算量太大，无法通过智能合约来完成；它必须使用Black-Scholes 模型等复杂算法在链下完成。如果用户想要计算加密代币衍生品的隐含波动率或期权价格，他们将获取这些代币在空间和时间上的价格历史记录，然后运行 ​​Black-Scholes 模型来计算期权价格或隐含波动率。在这种情况下，智能合约可以在交易发生之前直接从 Space and Time 查询数据，以确保交易时的价格正确、可验证。以下是该流程如何确保价格准确且防篡改：

1. 将模型的必要输入存储在空间和时间中。这些可能包括代币价格、执行价格、波动性和到期时间等参数。

2. 实现模型并使用存储的输入来计算期权价格。

3. 将生成的期权价格以及模型中使用的任何中间值或计算结果存储在空间和时间中。

4. 将从 Space and Time 检索实时期权价格的 SQL 查询发送到您的智能合约。

5. 使用 SQL 证明来验证查询及其结果的完整性，确保输入和输出未被篡改。

SQL 证明还使 Web3 之外的企业能够利用可验证的数据和计算，这对于财务价值与数据直接相关的行业尤其重要。例如，在银行财团分类账中，每个成员银行根据其各自的交易计算自己的损益表，这些交易存储在单独的数据库中。一旦计算出损益，银行就会将其记录在共享分类账上，其功能有点像区块链（可以添加交易，但不能删除或更改交易。联盟对添加的数据达成共识）。该账本成为该联盟的单一事实来源。

财团成员需要确信每家银行记录的损益是准确的，并且在添加到分类账之前没有被操纵。 SQL 证明允许这一过程以可验证的方式完成，因此任何银行都不必信任其他银行的完整性。当银行将其损益表添加到共享分类账中时，它提供了一个证据，保证其损益表是根据其数据库中的交易正确计算的……没有人操纵结果或用于计算结果的日内数据。

这种相互问责制度促进了联盟成员之间的信任和透明度。每家银行都可以确信共享账本包含准确可靠的财务数据，而不必信任其他机构。

如果您到目前为止一直坚持我的观点，您可能开始意识到这比智能合约、银行或数据库要大得多。 SQL 证明正在赋能未来，所有金融、经济和业务流程都不是建立在信任的基础上……而是建立在验证的基础上。验证一切的未来。

Space and Time 开创了第一个 zk 数据仓库，开启了验证时代，但我们设想的未来将远远超出 Space and Time。我们设想未来世界上的每个数据库都通过 SQL 证明进行验证，其中 SQL 证明是标准。我们很高兴能够继续朝着这个未来迈进，并期待在未来几个月分享更多里程碑。

https://www.spaceandtime.io/blog/proof-of-sql-101

打破时空小说的 zk 证明

Space and Time 推出了 Proof of SQL，这是一种针对 SQL 操作的新颖的 zk-proof，这是该项目任期内最受期待的时刻之一。该协议现已提供 alpha 版本，已交付给第一批项目，这些项目将使用该协议将可验证的查询连接到其智能合约。对于 Space and Time 的核心团队、社区和客户来说，此次发布是一个激动人心的时刻，也是我们创造的“验证一切”未来的一个巨大飞跃。

如果您一直关注 Space and Time 或 Web3 新闻周期，您可能听说过 SQL 证明。但除非您精通 zk 或者确实做了功课，否则您可能仍然想知道它到底是什么。 SQL 证明是一个 zk-SNARK，它以加密方式证明在空间和时间中运行的查询是准确的，并且查询和底层数据都是可验证的防篡改。如果这句话对您来说非常直观，您可以在此处了解有关如何开始使用 SQL 证明进行构建的更多信息。如果没有，请跟我一起，我们将解决它。

在解释一项复杂技术时，我喜欢从谈论它解决的问题开始。如果您尚未了解篡改查询的含义，那么防篡改查询的概念就没有意义。如果您还没有意识到系统不具备可验证性的后果，那么可验证性就没有多大意义。 SQL 证明不仅有可能从根本上改变 Web3，而且有可能从根本上改变世界商业和经济的整个数据基础。但是……怎么办？

为了回答这个问题，让我们回顾一下数据篡改的悠久且造成经济损失的历史。数据篡改是指有人操纵、更改或删除数据库中存储的信息。在许多情况下，数据篡改是由外部不良行为者（即：黑客）执行的。随着数据库在每个政府、行业和组织中变得无处不在，黑客攻击及其对企业造成的威胁使得价值2 万亿美元的网络安全产业得以蓬勃发展。公司比以往任何时候都更加投资于工具来保护其数据免受外部威胁，例如数据库内加密、基于角色的访问控制和多因素身份验证。

但恶意的外部行为者并不是公司唯一需要担心的事情。即使采取了最严格的安全措施，数据仍然容易受到可以说更大的威胁：内部人为错误。事实上，估计62% 的数据篡改事件是由有权访问数据的用户引起的。恶意、疏忽和受损的用户对组织的安全、生产力和声誉构成巨大（且代价高昂）的威胁。据估计，一次内部来源篡改数据的事件平均造成1,538 万美元的损失，这还不包括消费者信任度下降导致的收入损失。

就在今年，摩根大通因错误删除超过 470 万条电子邮件记录而被 SEC罚款400 万美元，此前该公司在 2021 年因未能保存其他通信记录而支付了 1.25 亿美元的罚款。该公司将责任归咎于其聘请来处理电子邮件数据存储的归档供应商，其中许多电子邮件是在 SEC 调查中通过传票寻求的。

今年 2 月，一名员工意外删除了处理速率限制的内部服务中的数据后，Twitter 经历了一次重大的站点范围内的停机。结果，大量用户无法发推或转发，而是收到一条错误消息，称他们已达到每日限额。

2021 年 4 月，达拉斯市解雇了一名 IT 员工，该员工鲁莽删除了达拉斯警方的20.68 TB数据，此举导致该市损失 50 万美元。这名接受过培训并有权访问数据的员工承认，他在没有检查这些表是否已备份的情况下就删除了这些表。该事件导致在大约 17,500 起刑事案件中作为证据收集的超过 870 万份档案丢失。仅 3TB 的丢失数据得以恢复。

随着网络安全行业的不断进步，有很多方法可以确保数据不被外部参与者操纵。但这些安全措施到哪里结束呢？例如，公司如何确保授权的数据库管理员不会犯下导致其损失数百万美元的错误？

好吧，这就是 SQL 证明的用武之地。 SQL 证明旨在保证两件事：在查询时，您获取的数据是正确的，并且自摄取以来没有被操纵过；您获得的查询结果是该数据的精确 SQL 计算。尽管此设计仅提供单个时间点的数据状态证明，但可以轻松地利用它来创建数据沿袭：始终数据状态的证明。您所需要做的就是按照您想要验证数据的频率设置定期运行状况检查查询 - 每隔几天、每隔几个小时，甚至每隔几秒。这将创建一个防篡改的血统，确保您的数据始终可追溯。

借助 SQL 证明，您不仅可以在篡改事件发生后立即捕获它，还可以轻松地将数据恢复到篡改前的状态。如果 DBA 不小心删除了一些表，公司就会对之前的数据进行防篡改审计跟踪。 SQL 证明允许数据库本质上充当防篡改账本，就像区块链一样，但具有业务运营所需的存储、计算和 SQL 接口。

Web3 中有一个完全独立的问题：智能合约无法提出数据驱动的问题。为了理解其中的原因，我们来讨论一下数据存储和计算在 Web3 堆栈中的位置。

区块链本质上只是一个包含单个不可变数据表的数据库。每次创建新交易时，数据都会添加到表中并永久存储在其中。如果区块链是链上存储，那么智能合约就是链上计算：一段旨在对区块链数据执行非常基本的 if/then 逻辑的代码。 “如果 X 发生，则交易 Y。”这对于简单的链上价值交换非常有效，但是对于需要更复杂计算的东西（例如期权交易）呢？就其本身而言，智能合约甚至无法提出一个简单的问题，例如“拥有该集合中的两个 NFT 的所有钱包是什么？”为了让智能合约“更智能”，你必须将它们连接到链下存储和计算；你必须给他们一种提问的方式。

SQL（代表结构化查询语言）是世界上提出问题的编程语言。这就是从微软到麦当劳的每个企业如何对数据进行计算——他们如何提出诸如“该产品上季度产生的总收入是多少？”之类的问题。他们都使用一种通用工具来完成此操作：SQL 数据库。

企业利用数据库的方式与 dapp 利用区块链的方式类似：存储、管理和检索数据。但与区块链不同的是，数据库非常高效，可以处理构建业务逻辑所需的更复杂的计算：确定系统内如何处理数据的规则。另一方面，数据仓库更加强大：它们是专门为处理分析而构建的企业级数据库。数据仓库为企业提供了一种从数据中收集见解的方法，支持趋势分析、报告和决策等任务。事务数据库和分析数据仓库都是企业数据管理堆栈的关键组成部分，并提供必要的存储和计算来补充区块链的存储和计算，并允许智能合约提出复杂的问题。

不幸的是，您不能将任何旧数据库或数据仓库（例如 PostgreSQL 或 Snowflake）连接到智能合约。其一，数据库没有预加载索引的区块链数据，智能合约必须能够知道链上发生了什么。更重要的是，链下数据库本身不会写回链，因此没有内置方法可以将您提出的问题的答案连接到智能合约。也许最重要的是，今天的数据库都需要一件与区块链根本不兼容的东西：信任。

去信任化是区块链技术的基石，也是区别于传统系统的关键因素。 “不可信”一词并不意味着区块链不可信；而是意味着区块链不值得信任。相反，它意味着用户不需要信任中央机构或中介来验证和执行交易。去信任性确保智能合约可以完全确定地执行其预定义的规则和条件，而无需外部各方的干扰或操纵。这对于自动化价值驱动流程（例如金融交易）至关重要，其中任何偏离预期行为的行为都可能产生严重后果。通过在去信任的环境中运行，智能合约保证了一致和透明的结果。

相比之下，传统数据库和数据仓库要求用户信任监督和管理系统的中央机构。这些集中式系统容易受到潜在的篡改、欺诈以及与单点故障相关的风险。将此类系统连接到智能合约会损害区块链技术的零信任模型。

看似显而易见的答案是去中心化数据库。去中心化数据库，例如 Space and Time 的去中心化 HTAP 数据仓库，将 SQL 数据库的高效计算能力引入区块链堆栈，而不会引入集中式、需要信任的故障点。在去中心化数据库中，数据分布在节点网络中，每个节点负责一部分数据。从表面上看，它似乎是对智能合约有限存储和计算的完美补充，Web3 领域的许多公司正在为此构建。

但是，除非数据和计算分布在足够多的节点上，以便有效的共识算法保证其完整性，否则信任仍然是一个因素。如果您的数据由单个节点操作员甚至少数节点操作员管理，您仍然需要相信操作员没有操纵任何内容。共识对于像以太坊这样的网络来说效果很好，因为交易会在数千个节点上复制，但随着节点数量的减少，它的效率也会降低。我们在区块链网络中看到的这种极其冗余的复制首先就是它们存储和计算如此有限的原因。所以你会怎么做？如何构建一个高效的去中心化数据库，以完全不信任的方式向智能合约提供查询结果？为此，您需要零知识证明。

SQL 证明是一种 zk 证明，可提供加密保证，确保您的数据和查询结果没有被运行数据库集群的节点操作员操纵。与依赖多个节点就数据有效性达成共识的共识不同，零知识证明允许一方证明陈述的正确性，而无需透露任何其他信息。对于 SQL 证明，它可以确保您正在查询的数据是正确的，并且自摄取以来没有被篡改，并且您收到的查询结果是该数据的准确 SQL 计算。

需要 SQL 证明来保证去中心化数据网络的去信任性，而不需要不必要的节点复制或依赖共识。这使得智能合约能够提出复杂的、数据驱动的问题并获得可信的答案，从而扩展其潜在的应用程序和功能。借助 SQL 证明，您可以实现 SQL 数据库的效率以及区块链的安全性和防篡改血统。这项技术让企业和 dapp 能够自信地利用链下存储和计算来补充智能合约的有限容量，为 Web3 应用释放新的可能性，让智能合约变得“更智能”。

现在我们已经解决了 SQL 证明解决的两个主要问题，我们可以进一步深入研究它的工作原理。我们知道 SQL 证明保证以下内容：

1. 在数据被摄取和查询之间，数据没有被操纵。

2. 您收到的查询结果是对存储数据的准确计算。

3. 查询结果本身在返回给您之前没有被篡改。

但让我们看看如何做。请记住，我们只会按照普通人（阅读：非密码学家）的需要深入了解幕后发生的事情。如需更深入的了解，请查看由 Space and Time 联合创始人、研究主管兼协议创建者 Jay White 撰写的Proof of SQL 文档。

下图显示了高级 SQL 架构的证明：

Zk 证明是一种协议，其中不受信任的证明者让验证者相信某个陈述是真实的，而无需共享任何附加信息。与任何 zk-proof 架构一样，Proof of SQL 由两个组件组成：证明者和验证者。这些组件的名称很好，并且功能与听起来完全一样：证明者生成证明，验证者对其进行验证。换句话说，将证明者视为提出主张的人，将验证者视为检查该主张是否属实的人。

在《空间与时间》中，当您使用 SQL 证明运行查询时，数据仓库（存储数据的位置）充当证明者。它生成一个证明，表明查询结果是准确的并且未被篡改。该证明是使用复杂的加密算法生成的，这需要大量的计算能力。幸运的是，数据仓库基于 NVIDIA GPU 构建，GPU 专为并行处理（相对于顺序处理）而设计，因此对于此类计算来说比 CPU 快得多。这意味着即使计算量很大，也可以相对快速地生成证明。而且由于该协议不要求证明者是不可信的（仅要求验证者），因此每个查询只需执行一次。

验证者的工作是检查证明并确保其正确。验证在计算上足够轻量，可以通过空间和时间验证器层、去中心化的预言机网络或智能合约冗余地完成，所有这些都确保了协议的去信任性。 Proof of SQL 团队正在构建轻量级验证，最终甚至可以通过运行客户端库的 iPhone 等设备来执行。

让我们一步一步地过一遍防篡改查询的过程。

当数据被摄取到空间和时间时，无论是我们从主要区块链索引的数据，还是从游戏、应用程序或其他数据库加载的数据，它首先都会通过验证器层进行路由。验证器捕获数据的承诺（我们称之为“指纹”）并将其存储起来以供以后使用。 （注：我之前提到过，验证也可以通过智能合约来完成。这是因为，与一次可能有几 GB 的原始数据不同，指纹很小，并且可以以经济实惠的方式存储在链上） 。接下来，验证器将原始数据发送到存储它的数据仓库。

当您通过 API、JDBC 驱动程序或 Space and Time Studio 发送查询请求时，验证器会将其路由到数据仓库。 （验证器还负责确定查询是事务性的还是分析性的，并将其路由到适当的 OLTP 或 OLAP 引擎，这非常简洁，但您可以在此处阅读更多相关信息）。

数据仓库解析查询，计算正确的结果，并生成加密证明，证明在计算查询时没有任何内容被篡改。然后它将查询结果和证明发送回验证者。

然后验证者检查证据、查询结果和存储的数字指纹，以确认数据在摄取时间和查询时间之间没有更改。瞧！您已经获得了防篡改的查询结果。

希望此时您对 SQL Proof 是什么、它如何工作以及它解决什么问题有一个全面的（尽管是高层次的）理解，这应该为您提供更好的基础上下文来理解它的一些用例。我们将介绍其中的两个。

让我们回到去中心化期权交易的例子。在这篇博文的前面，您读过以下内容：

“[智能合约]对于简单的链上价值交换非常有效，但是对于需要更复杂计算的东西（例如期权交易）又如何呢？就其本身而言，智能合约甚至无法提出一个简单的问题，例如“拥有该集合中的两个 NFT 的所有钱包是什么？”为了让智能合约“更智能”，你必须将它们连接到链下存储和计算；你必须给他们一种提问的方式。”

现在您知道 SQL 证明是缺失的部分，它允许智能合约询问和回答有关其自己链上的数据、其他链上的数据的数据驱动的问题（在此处阅读有关空间和时间区块链索引服务的更多信息），以及从任何链外源加载的数据。这使得 SQL 证明特别适合数据驱动的 DeFi 协议，例如去中心化期权交易平台。

期权是一种金融工具，赋予交易者在特定时间范围内以预定价格购买或出售标的资产（例如加密货币）的权利。在 Web3 中，期权交易通过智能合约实现自动化。 SQL 证明允许这些智能合约实时查询定价信息，并保证他们获得的信息准确且未被操纵。

计算期权价格的计算量太大，无法通过智能合约来完成；它必须使用Black-Scholes 模型等复杂算法在链下完成。如果用户想要计算加密代币衍生品的隐含波动率或期权价格，他们将获取这些代币在空间和时间上的价格历史记录，然后运行 ​​Black-Scholes 模型来计算期权价格或隐含波动率。在这种情况下，智能合约可以在交易发生之前直接从 Space and Time 查询数据，以确保交易时的价格正确、可验证。以下是该流程如何确保价格准确且防篡改：

1. 将模型的必要输入存储在空间和时间中。这些可能包括代币价格、执行价格、波动性和到期时间等参数。

2. 实现模型并使用存储的输入来计算期权价格。

3. 将生成的期权价格以及模型中使用的任何中间值或计算结果存储在空间和时间中。

4. 将从 Space and Time 检索实时期权价格的 SQL 查询发送到您的智能合约。

5. 使用 SQL 证明来验证查询及其结果的完整性，确保输入和输出未被篡改。

SQL 证明还使 Web3 之外的企业能够利用可验证的数据和计算，这对于财务价值与数据直接相关的行业尤其重要。例如，在银行财团分类账中，每个成员银行根据其各自的交易计算自己的损益表，这些交易存储在单独的数据库中。一旦计算出损益，银行就会将其记录在共享分类账上，其功能有点像区块链（可以添加交易，但不能删除或更改交易。联盟对添加的数据达成共识）。该账本成为该联盟的单一事实来源。

财团成员需要确信每家银行记录的损益是准确的，并且在添加到分类账之前没有被操纵。 SQL 证明允许这一过程以可验证的方式完成，因此任何银行都不必信任其他银行的完整性。当银行将其损益表添加到共享分类账中时，它提供了一个证据，保证其损益表是根据其数据库中的交易正确计算的……没有人操纵结果或用于计算结果的日内数据。

这种相互问责制度促进了联盟成员之间的信任和透明度。每家银行都可以确信共享账本包含准确可靠的财务数据，而不必信任其他机构。

如果您到目前为止一直坚持我的观点，您可能开始意识到这比智能合约、银行或数据库要大得多。 SQL 证明正在赋能未来，所有金融、经济和业务流程都不是建立在信任的基础上……而是建立在验证的基础上。验证一切的未来。

Space and Time 开创了第一个 zk 数据仓库，开启了验证时代，但我们设想的未来将远远超出 Space and Time。我们设想未来世界上的每个数据库都通过 SQL 证明进行验证，其中 SQL 证明是标准。我们很高兴能够继续朝着这个未来迈进，并期待在未来几个月分享更多里程碑。

https://www.spaceandtime.io/blog/proof-of-sql-101