注册
关闭
区块链大帝

区块链大帝

发布于 2020-01-23 阅读数 5040

科普 | 如何利用零知识证明改造区块链(大白话篇)

原文链接:medium

作者: Ronald Mannak

翻译 & 校对: 曾汨 & 阿剑

来源:以太坊爱好者

 

已经有许多技术博客发表了关于零知识证明(ZKP)的文章。最近,我自己写了一篇文章,比较了新的通用型 zk-SNARK。我注意到,用浅白的语言来解释 ZKP 用例的文章还寥寥无几。其实,ZKP 不仅仅可以用于保护隐私,由于其丰富多样的功能,ZKP 甚至可以改变区块链运行的方式。

 

首先:简洁的区块链,从 GB 到 KB

因为区块链的数据规模会随着新区块的产生而不断增长,所以其规模可能会变得很大。这是设计使然,我们已经开始接受这一现实。然而,最近上线的 Coda 测试网却有些与众不同。首先, Coda 的区块链数据规模恒定,并不会增长。其次,它的整条区块链大小只有 22kb!这意味着哪怕你用一台上世纪 80 年代的 Commodore 64 或者 ZX Spectrum 来跑节点也毫不费力。然而,相较于传统的区块链而言,Coda 的安全性有过之而无不及。还有越来越多的项目正在朝着这方面发展:Mir 和 Starling(我是 Starling 的一员) 将在不久后启动与 Coda 相似但功能更加丰富的 “简洁的区块链”。那它们到底是怎么做的呢?

任何一个运行过区块链节点的人都经历过这样的痛苦:同步一个节点需要耗费几个小时甚至数天。区块链的数据量往往非常巨大,以至于绝大多数家庭的电脑硬盘和带宽都达不到运行节点的要求。这就导致了中心化。即便是像以太坊这样广受欢迎的区块链,全网也只有大约 10,000 个节点。其中大部分节点还是被托管在 AWS 上的,并且归属于少数实体。区块链并没有许多人认为的那样去中心化。

为什么同步一条区块链要花这么长的时间?有两个原因。第一个原因显而易见:下载数百 GB 甚至更多的数据需要耗费一段时间。其次,当节点下载完数据后,还需要对整条区块链进行验证,因为可能会有恶意的节点给你发送错误的数据。

要想验证一条区块链,必须从创世区块开始重放:执行第一笔交易,确认计算出的状态与下载到的状态一致。然后验证下一笔交易,直到你验证完整条区块链中所有的交易。这样做既耗时费力;而且在你之前,已经有成千上万的节点执行过同样的计算。

但这样做是必要的,因为在传统的计算模式中,知道计算是否正确的唯一方法就是重新再算一次。这对于小型计算来说还好,但对于比较大的计算量而言就不太友好了,比如重放区块链。

 

利用 ZKP 改善效率及带宽利用

事实证明,有一种技术可以在无需重新计算的前提下降低验证计算结果的成本:零知识证明(ZKP),而 zk-SNARK 可能是所有零知识证明技术中最出名的。

所以到底怎么结合呢?我们必须将区块链的重放函数用 zk-SNARK 重写一遍。zk-SNARK 将输出两样结果:初始输出(就像初始的重放函数会输出的结果一样)和一个小型的数学证明,用于证明该计算结果是正确的。这个证明可以小到只有 200 Bytes(是的,你没看错,不到 1KB)。

无需让所有的(甚至多台)计算机都执行重放函数。只需要有一台计算机创建证明,其它所有计算机都可以按自己的需要验证结果。验证只需要花费几毫秒,不论初始的计算花了多长时间(甚至是几个小时、几天或几年,都无关紧要)。这些证明可以发布到网络上、通过 U 盘传播,甚至打印在 T 恤上。

如果有一个恶意的节点改动了余额,那么其证明就会和结果不匹配,所有验证者都会拒绝该状态。如果恶意的节点对 zk-SNARK 的代码动了手脚,其结果也会被其它节点拒绝。(系统中还存在第三个参数 —— 一个公开的共享字符串,它将证明和 zk-SNARK 代码绑定在了一起。一旦代码被动了手脚,其证明就会和和共享字符串匹配不上,于是验证者就会拒绝该计算结果。)

我们已经摆脱了对重复进行昂贵计算的依赖,同时也不再需要下载整条区块链了(因为我们已经有了数学证明来证明区块链的存在及有效)。你只需要下载当前的状态(例如最新的区块)加上一个很小的证明,用于证明当前状态是有效区块链的一部分,然后花费几毫秒来验证计算结果。

 

递归组合(Recursive composition)

验证证明的过程非常快,可创建证明的过程呢?事实证明,创建证明所耗费的时间并不是固定的,相较于传统的计算而言,该过程在计算和内存方面要低效得多。事实上,尽管采用了 zk-SNARK 的重放函数听上去很美好,但它实践起来并不是一个优秀的解决方案。它会消耗巨大的内存,甚至比最初的非 zk-SNARK 重放函数还要慢。

但如今有了另一种优雅的解决方案。通过一些小技巧,我们可以使用递归的 zk-SNARK。通过递归,我们不再需要从头开始验证区块链,而可以在上一个状态的基础上构建新的状态。这要快得多。请注意,递归的 zk-SNARK 并没有非递归的 zk-SNARK 效率高,但最近 zk-SNARK 构建已取得了巨大的进步。

递归的 zk-SNARK 程序使用上一个状态、该状态的证明以及新的交易作为输入。它(使用提供的证明)验证上一个状态,并检查新状态中的交易是否有效。如果有效,它将输出新状态及其证明。

一旦新状态和证明分发到了网络中,所有节点都可以直接抛弃旧的状态,而不用担心产生任何负面后果。新节点只需要下载最新的状态及其证明就可以了。这就为什么 Coda、Mir、和 Starlin 能实现数据规模恒定的区块链。

在我们上一个例子中,只有一个节点会创建新的区块及证明。很显然,并非所有区块都必然是同一个节点产生的。例如,可以从众多节点中随机选择一个节点来创建区块(如果采用了可验证的随机函数(Verifiable Random Function),节点们甚至可以在内部选出节点来出块,且无法作恶)。我们甚至可以做的更好。我们可以将区块生产的逻辑划分为多个 zk-SNARK。

最终的结果就是区块生产者不需要再保存整条区块链,而只需要保存上一个状态。这种解决方案可以小多少呢?一个常规的 Coda 节点只需要占用 22KB 的空间用于存储证明、当前状态和指向一个余额的默克尔路径。通过 22KB 的存储,节点可以验证整条区块链、查询余额、以及创建交易。但要想生产区块,节点需要做更多的操作:它需要上一个状态的全余额默克尔树。默克尔树的大小取决于钱包的数量。即便 Coda 拥有的钱包数量和以太坊一样多,一个 Coda 的区块生产者仍然只需要 1GB 大小的存储空间。而最小的以太坊全节点则需要 230GB(截止 2019 年 12 月)。这是一个巨大的差距。

通过这种方式,网络中会有更多活跃的节点,进而增加其去中心化程度,并为与区块链交互的程序开辟了许多新的可能性,而不用再借助诸如 Infura 或 Metamask 等解决方案。考虑到 99% 的用户在安装 Metamask 之前就已经放弃了,这应该会带来巨大的影响。

感谢 Daniel Lubarov (Mir)、Shane Vitarana、Stan van de Burgt、Taariq Lewis、和 Dmitriy Berenzon 对本文的校对。

(完)

  • 0
区块链大帝
区块链大帝

0 条评论