让我们用非技术语言告诉你,零知识证明如何改变区块链
2020-02-20 17:40
链闻
2020-02-20 17:40
订阅此专栏
收藏此文章
用最简单方式说透「精简区块链」实现方式和巨大价值。


撰文:Ronald Mannak,区块链创业公司 Starling Protocol 联合创始人兼 CEO

编译:卢江飞


关于零知识证明(ZKP)的技术类博客文章很多,最近我也写了一篇文章,比较各种新的通用目的的 zk-SNARK。我发现,关于零知识证明的用例,很少有用非技术语言表述的文章。事实上,零知识证明不仅可用在隐私方面,还有许多其他用途。它功能如此丰富,甚至有可能重新定义区块链的运作方式。


精简区块链,从 GB 压缩到 KB


区块链的区块可能会很大,而且其大小在不断增长。这源于其最初的设计。我们也渐渐接受了这个现实。但是,Coda 项目最近发布的测试网却不同。


首先,Coda 的区块链是固定大小的,且不会增长;其次,它只有 22KB!即便是上世纪 80 年代的 8 位机家用电脑 Commodore 64 或 ZX Spectrum,也能把它塞进去。而且,与传统的区块链相比,Coda 的安全性差不多,甚至更高。


类似但功能更多的「精简区块链」项目越来越多,比如 Mir 和 Starling(我本人也参与了 Starling 项目)。


这到底是如何做到的呢?


只要尝试部署过一个区块链节点,你就会知道这个过程有多痛苦:同步一个节点需要好几个小时、甚至数天时间。区块链如此之大,以至于大多数的家用计算设备的磁盘空间和带宽都达不到基本要求。结果就是中心化。即便像以太坊这样广受欢迎的区块链,其节点数量也就 10,000 个,大多数都托管在亚马逊 AWS 上,由少数几个实体所拥有。区块链并不像许多人以为的那么去中心。


为什么同步一个区块链要这么长时间呢?主要有两个原因:


第一个原因很明显:下载几百 GB 或更多数据需要很长时间;


第二,下载完之后区块链要完成验证,因为恶意节点可能会向你发送不正确的数据。


若要验证一个区块链,必须从创世区块开始重放(replay)整条链:执行第一个交易,并确保计算出的状态等于下载得到的状态。然后转到下一个交易,直到你把区块链的所有交易都查一遍。这不仅耗时,也浪费资源。在你之前,成千上万的节点做着完全相同的计算工作。


为什么要这么做呢?因为在传统计算学里,要知道一个计算是否正确的执行,唯一办法就是重做一次这个计算。如果小规模的计算,那就还好,但像重放一条区块链这种「慢运算」(slow calculation),情况就完全不同了。


可提高效率和带宽的零知识证明


事实上,有一种方法可以低成本地验证一个计算结果,而又无需重做该计算,那就是零知识证明(ZKP),其中最著名的可能要数 zk-SNARK。


它是如何工作的呢?我们需要将区块链的重放函数改写为一个 zk-SNARK。这个 zk-SNARK 将输出两个东西:原初的输出(就跟原来的重放函数一样); 一个很小的数学「证明」,证明这个结果计算正确。这个「证明」可以小到只有 200 字节(没错,还不到 1KB)。


这样一来,我们就不需要所有(或是多台)计算机跑一遍重放函数了。由一台计算机去创建这个「证明」,其他不限数量的计算机可以在它们认为合适的时间再进行验证。无论原初的计算要花费多长时间(即使是几小时、几天、甚至几年都没有关系),验证却只需几毫秒即可搞定。这个「证明」可以通过线上分发,也可以存储在 U 盘里,甚至可以印在 T 恤上。


如果有恶意节点更改了某个交易的余额,那么这个「证明」就会和结果不同,所有验证者都会拒绝这个状态。如果有恶意节点更改了 zk-SNARK 代码,结果也会被拒绝。(有一个「第三参数」、一个公开共享的字符串,会把这个「证明」绑到这个 zk-SNARK 代码。如果代码被修改,那么这个「证明」和共享的字符串将不匹配,于是验证者就会拒绝该结果。)


我们不再需要重做昂贵的计算,也不需要下载区块链(因为我们已经有了关于该区块链存在且有效的数学证明)。你需要的,只是当前状态(比如最后一个区块),加上能够证明当前状态是一个有效区块链的一部分的少量「证明」,再花费几毫秒验证一下结果。


递归性的组合


验证一个「证明」的速度很快,但创建这个「证明」怎样呢?其实时间不固定,与传统计算相比,在计算和和内存方面它的效率要低不少。实际上,虽然一个重放函数的 zk-SNARK 版本听起来不错,但在实践中这个解决方案并不好。和以往的非 zk-SNARK 的重放函数相比,它需要更大的内存,速度甚至更慢。


不过,还有另一个优雅的方案。我们发现,用一点点小技巧,其实可以使用递归性 zk-SNARKs 。有了递归,我们就不必从头开始验证这个区块链,可以在前一个状态的基础上来构建。速度会快得多。


需要注意的是,递归性 zk-SNARK 的效率依然不如非递归的 zk-SNARK ,不过,最近 zk-SNARK 的构造取得了长足的进步。


一个递归性的 zk-SNARK 程序,会用属于「前一个状态」(previous state)的「证明」和新的交易作为输入。它会(用已被提供的证明)验证前一个状态,并检查新状态中的交易是否有效。如果没问题,它会输出新的状态和一个「证明」。


一旦新的状态和「证明」被分发到网络中,所有节点可以直接丢弃先前的状态,这么做不会有任何负面影响。新的节点只需要下载最新的状态和「证明」即可。这也就是Coda、Mir 和 Starling 这些项目可以实现小的、大小固定的区块的秘诀。


在上面说的这个例子里,只需要一个节点来创建新的区块和「证明」。显然,我们没必要让同一个节点来生成所有的区块。举个例子,可以从许多节点中随机选择一个节点(用「可验证随机函数」,众多节点甚至可以随机自我选择而不会有欺骗行为)。我们甚至可以做得更好:将区块的生成逻辑分为多个 zk-SNARK。


最终结果就是:区块生产者不需要完整的区块链,它只需要前一个状态。这会让区块大小降到多少呢?一个常规的 Coda 节点仅需要 22 KB 即可存储「证明」、当前状态以及某个账户余额的 Merkle 路径。只需要 22KB,一个节点就能验证整个区块链、查询余额并创建交易。但是,如果要生成区块,这个节点需要更多:它需要先前状态的全部余额的 Merkle 树。而 Merkle 树的大小取决于钱包的数量。如果 Coda 拥有和以太坊一样多的钱包,那么,Coda 区块生产者也只需要大约 1 GB 的容量。而以太坊上最小的完整节点是 230 GB(2019 年 12 月的数据)。差距巨大。


利用零知识证明,区块链网络将有更多活跃节点,这就提升了去中心化程度,并让各种程序有更多可能与区块链进行交互,而无需像 Infura 或 Metamask 这样的方案。想想看,99% 的新用户在安装 Metamask 时选择了放弃。所以,这种变化将带来巨大的影响。


感谢以下各位对本文的审阅: Daniel Lubarov (Mir), Shane Vitarana, Stan van de Burgt, Taariq Lewis,和Dmitriy Berenzon。作者授权链闻翻译并发布该文中文版本。

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

相关Wiki
链闻
数据请求中
查看更多

推荐专栏

数据请求中
在 App 打开