SxT:Proof of SQL 101

本月早些时候,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,而且有可能从根本上改变世界商业和经济的整个数据基础。但是……怎么办?

问题#1:数据篡改

材料又贵

为了回答这个问题,让我们回顾一下数据篡改的悠久且造成经济损失的历史。数据篡改是指有人操纵、更改或删除数据库中存储的信息。在许多情况下,数据篡改是由外部不良行为者(即:黑客)执行的。随着数据库在每个政府、行业和组织中变得无处不在,黑客攻击及其对企业造成的威胁使得价值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 接口。

问题#2:智能合约无法提问

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

有限的链上存储和计算

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

链下数据库是解决方案吗?

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

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

中心化系统需要信任

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

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

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

去中心化数据库与零知识数据库

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

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

经过 Zk 验证的查询结果及其功能

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

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

怎么运行的

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

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

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

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

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