已经有许多技术博客发表了关于零知识证明（ZKP）的文章。最近，我自己写了一篇文章，比较了新的通用型 zk-SNARK。我注意到，用浅白的语言来解释 ZKP 用例的文章还寥寥无几。其实，ZKP 不仅仅可以用于保护隐私，由于其丰富多样的功能，ZKP 甚至可以改变区块链运行的方式。
因为区块链的数据规模会随着新区块的产生而不断增长，所以其规模可能会变得很大。这是设计使然，我们已经开始接受这一现实。然而，最近上线的 Coda 测试网却有些与众不同。首先， Coda 的区块链数据规模恒定，并不会增长。其次，它的整条区块链大小只有 22kb！这意味着哪怕你用一台上世纪 80 年代的 Commodore 64 或者 ZX Spectrum 来跑节点也毫不费力。然而，相较于传统的区块链而言，Coda 的安全性有过之而无不及。还有越来越多的项目正在朝着这方面发展：Mir 和 Starling（我是 Starling 的一员） 将在不久后启动与 Coda 相似但功能更加丰富的 “简洁的区块链”。那它们到底是怎么做的呢？
火币推出《一分钟读懂DeFi》系列科普视频:据官方消息，8月24日，火币推出《一分钟读懂DeFi》系列科普视频，并与微博财经合作冠名播出，布道DeFi认知，助力行业发展《一分钟读懂DeFi》是由火币成长学院打造的业内首个系统全面讲解DeFi的系列科普动画，继推出《区块链100问》后的再续佳作。《一分钟读懂DeFi》系列动画对DeFi的发展进行系统梳理，适合想要由浅入深、全面系统了解区块链DeFi的人们轻松了解DeFi。目前视频已由火币网官方微博发布。[2020/8/24]
任何一个运行过区块链节点的人都经历过这样的痛苦：同步一个节点需要耗费几个小时甚至数天。区块链的数据量往往非常巨大，以至于绝大多数家庭的电脑硬盘和带宽都达不到运行节点的要求。这就导致了中心化。即便是像以太坊这样广受欢迎的区块链，全网也只有大约 10,000 个节点。其中大部分节点还是被托管在 AWS 上的，并且归属于少数实体。区块链并没有许多人认为的那样去中心化。
人大附中物理老师李永乐科普拜占庭将军问题和区块链:5月14日，人大附中物理老师、科普视频网红李永乐在其公众号发布视频《拜占庭将军问题是什么？区块链如何防范恶意节点？》。李永乐老师在视频中对拜占庭将军问题和区块链进行了讲解，他表示，拜占庭将军问题本质上指的是，在分布式计算机网络中，如果存在故障和恶意节点，是否能够保持正常节点的网络一致性问题。在近40年的时间里，人们提出了许多方案解决这一问题，称为拜占庭容错法。例如兰波特自己提出了口头协议、书面协议法，后来有人提出了实用拜占庭容错PBFT算法，在2008年，中本聪发明比特币后，人们又设想了通过区块链的方法解决这一问题。区块链通过算力证明来保持账本的一致性，也就是必须计算数学题，才能得到记账的权力，其他人对这个记账结果进行验证，如果是对的，就认可你的结果。与拜占庭问题比起来，就增加了叛徒的成本。[2020/5/14]
为什么同步一条区块链要花这么长的时间？有两个原因。第一个原因显而易见：下载数百 GB 甚至更多的数据需要耗费一段时间。其次，当节点下载完数据后，还需要对整条区块链进行验证，因为可能会有恶意的节点给你发送错误的数据。
动态 | 报告：区块链等热点词促使童书科普百科类成交额同比增速最高:近日，京东图书与艾瑞咨询联合发布了《2019中国图书市场报告》。报告指出，AI、5G、区块链、机器人、VR、智能家居、AR这些热点词，不断点燃科技热潮，科技在改变大众生活的同时，也吸引了越来越多家长的关注，从小培养孩子对科技的兴趣和热爱。因此童书中科普百科类成交额同比增速最高，占比将近40%。[2020/1/8]
要想验证一条区块链，必须从创世区块开始重放：执行第一笔交易，确认计算出的状态与下载到的状态一致。然后验证下一笔交易，直到你验证完整条区块链中所有的交易。这样做既耗时费力；而且在你之前，已经有成千上万的节点执行过同样的计算。
但这样做是必要的，因为在传统的计算模式中，知道计算是否正确的唯一方法就是重新再算一次。这对于小型计算来说还好，但对于比较大的计算量而言就不太友好了，比如重放区块链。
科普时报：区块链与云计算长期发展目标不谋而合:据《科普时报》今日报道，区块链与云计算两项技术的结合，从宏观上来说，一方面，利用云计算已有的基础服务设施或根据实际需求做相应改变，实现开发应用流程加速，满足未来区块链生态系统中初创企业、学术机构、开源机构、联盟和金融等机构对区块链应用的需求。另一方面，对于云计算来说，“可信、可靠、可控制”被认为是云计算发展必须要翻越的“三座山”，而区块链技术以去中心化、匿名性，以及数据不可篡改为主要特征，与云计算长期发展目标不谋而合。[2018/5/4]
事实证明，有一种技术可以在无需重新计算的前提下降低验证计算结果的成本：零知识证明（ZKP），而 zk-SNARK 可能是所有零知识证明技术中最出名的。
所以到底怎么结合呢？我们必须将区块链的重放函数用 zk-SNARK 重写一遍。zk-SNARK 将输出两样结果：初始输出（就像初始的重放函数会输出的结果一样）和一个小型的数学证明，用于证明该计算结果是正确的。这个证明可以小到只有 200 Bytes(是的，你没看错，不到 1KB)。
财政部副部长朱光耀：数字经济还处在发展的过程中，要以科普、推动的态度来推进数字经济发展:今日，在中国发展高层论坛2018年会上，财政部副部长朱光耀表示：“数字经济还处在发展的过程中，要以科普、推动的态度来推进数字经济发展。也要关注数字经济的其他影响，包括税收征管、反监管措施等要跟上。”[2018/3/25]
无需让所有的（甚至多台）计算机都执行重放函数。只需要有一台计算机创建证明，其它所有计算机都可以按自己的需要验证结果。验证只需要花费几毫秒，不论初始的计算花了多长时间（甚至是几个小时、几天或几年，都无关紧要）。这些证明可以发布到网络上、通过 U 盘传播，甚至打印在 T 恤上。
如果有一个恶意的节点改动了余额，那么其证明就会和结果不匹配，所有验证者都会拒绝该状态。如果恶意的节点对 zk-SNARK 的代码动了手脚，其结果也会被其它节点拒绝。（系统中还存在第三个参数 —— 一个公开的共享字符串，它将证明和 zk-SNARK 代码绑定在了一起。一旦代码被动了手脚，其证明就会和和共享字符串匹配不上，于是验证者就会拒绝该计算结果。）
我们已经摆脱了对重复进行昂贵计算的依赖，同时也不再需要下载整条区块链了（因为我们已经有了数学证明来证明区块链的存在及有效）。你只需要下载当前的状态（例如最新的区块）加上一个很小的证明，用于证明当前状态是有效区块链的一部分，然后花费几毫秒来验证计算结果。
验证证明的过程非常快，可创建证明的过程呢？事实证明，创建证明所耗费的时间并不是固定的，相较于传统的计算而言，该过程在计算和内存方面要低效得多。事实上，尽管采用了 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 对本文的校对。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。