SNARK 与区块链的未来

作者：Ruben Somsen

来源：https://medium.com/@RubenSomsen/snarks-and-the-future-of-blockchains-55b82012452b

SNARK（succinct non-interactive argument of knowledge，简洁的非交互式知识证明）常被认为是 “解决” 扩容问题的灵丹妙药。虽然 SNARK 可以提供难以想象的好处，但我们也要知道 —— SNARK 无法解决区块链当前面临的带宽约束问题。

本文希望能通过（相对）简要地介绍 SNRAK 能为区块链做什么和不能做什么，来揭开 SNARK 的神秘面纱。我们会先谈谈，为什么它与区块链有关的功能可以被简洁地归纳为 “非交互式见证数据压缩（NIWA）”。只要你知道比特币是怎么运行的，你就能理解这篇文章。

- NIWA 在行动。SNARK 消耗 witness，但自身也是一个 witness。所以 SNARK 可以吞吃 SNARK -

应当指出的是，SNARK 在很大程度上仍然处于活跃的研究阶段。许多 SNARK 的变种，要么效率不足以至于无法证明复杂的语句（statement），要么证明的体积非常大，大到不切实际，要么需要一个受信任的启动设置（trused setup）。也就是说，虽然这几年我们看到了许多进展，预计未来数十年我们还将看到更多。本文的写作对这些进展有预期，即使它们今天看来可能不实用。

什么是 SNARK ?

SNARK 是一种技术，让你可以在给定一个规则集和一个起始状态时，高效地验证一个结果。导致这个结果的输入是不公开的（“零知识性”）。听起来一头雾水？我们拿象棋举一个简单的例子的好了。

象棋案例

1. 规则：象棋规则

2. 起始状态：棋盘的起始局面 A

3. 结果：棋盘的新局面 B

证明棋局从局面 A 到局面 B 是有效转换的传统方法是公开每一个步骤并检查每一步是不是都有效。SNARK 也同样能用来检查状态转换的有效性，但效果更好：

1. 步骤不必公开（隐私性、节约数据）

2. 验证在计算上更高效

但有一个问题 —— 创建 SNARK 的计算成本很高。不过，在一个许多人都想验证同一个结果的系统（比如区块链）中，使用这种技术可能仍是值得的。只需要一个人花力气来创建 SNARK，就能提高所有人的验证效率。

区块链案例

1. 规则：全节点软件

2. 起始状态：时间点 A 的区块头和 UXTO 集合哈希值

3. 结果：时间点 B 的区块头和 UTXO 集合

类似于我们上面提到的象棋，验证状态转换有效性的常规方法是：从时间点 A 的 UTXO 集合（所有未花费的交易）开始，接收截至 B 点所有的区块并更新 UTXO 集合。有了 SNARK，那就不需要这些数据来证明有效性了。实际上，如果时间点 A 被设为创世区块（空的 UTXO 集合），而时间点 B 被设成现在，那么无需接收任何历史数据就能验证整条链。

重要的是，你需要 B 点的整个 UTXO 集合，而关于 A 点你只需要知道 UTXO 集合的哈希值。虽然这个数据不是证明有效性严格必需的，但我们也关心 可得性。如果你总是只能拿到 UTXO 集合的哈希值，那即使你知道一个有效的状态存在，你也不能知道那个状态究竟是什么。也就是说你没法花费任何资金，因为你没有数据来证明某个 UTXO 属于当前的集合。如果以象棋为类比，那就是你知道了一个新局面的哈希值，但你并不知道那个局面到底是怎么样的，所以也没法继续玩这个游戏。

记住，无论是谁来创建 SNARK（假设是矿工）都要具备这个数据（结果 UTXO 集合）（因为这是创建 SNARK 必需的），但他们可能会选择扣住数据，不发给你。

SNARK 区块链

为了保证每个人都会花费自己的钱，更新 UTXO 集合所需的所有数据都必须与每个区块一起传播。你还是要知道哪些 UTXO 被花费了（即输入）、哪些 UTXO 新产生了（输出）。这就是所谓的 “非见证数据”。

状态转换的有效性可以靠一个 SNARK 来验证，因此 SNARK 可以取代所有的见证数据（脚本、签名），而且几乎不占用带宽。输入和输出之间的关联将被抹消 —— 一个区块看起来就像一笔很大的 coinjoin 交易一样。大部分数据都是非见证数据。

所以，与大众的想象相反，SNARK 无法解决轻客户端或者非联盟侧链背后的根本问题，因为你必须下载非见证数据。如果非见证数据丢失，全节点有能力拒绝一个有效的 SNARK；但如果一个轻客户端疏忽于下载非见证数据，它可能会错误地认为一个数据丢失的链是有效的。即使非见证数据的一小块被矿工扣住了，其他人也就没法在有效的 SNARK 上创建新区块 —— 最终它会变成一个许可型系统。

SNARK 消耗见证数据

用于区块链的 SNARK 最好的总结可能是，它可以启用一种功能：非交互的见证聚合（NIWA）。

我在这里使用 “见证” 一词是比较随意的。在比特币中，见证数据是放在交易中、用来证明具体的 UTXO 是否能够合法创建出来的数据。但随着时间推移，这个 UTXO（非见证数据）也会变成自身的见证数据，在它被花费的时候。假设 1 btc 从 Alice 转给了 Bob 又转给了 Carol，Bob 的交易就是从 Alice 到 Carol 的转账的见证数据。同样地，创世块以来的所有支付交易，都是当前 UTXO 集合的见证数据s。

同样要指出的是，一个 SNARK 自身就是一个见证数据。如果每一笔交易都由一个 SNARK 来验证，我们也可以将这些 SNARK 都聚合（NIWA）在一起、为区块生成单个的 SNARK。而且，因为输出在花费时会变成见证数据，我们甚至可以在交易池中取出未上链确认、但已经被花费的输出，并聚合它们。Alice 转给 Bob 再转给 Carol 会变成 Alice 转给 Carol，实现非交互的交易合并（transaction cut-through）。当带有许多链外交易分支的单个 UTXO 被强制上链时（比如闪电网络通道工厂），这种功能特别有用。

简单总结

我们已经用 NIWA 概念总结了 SNARK 为区块链提供的核心功能。任何见证数据都可以被一个 SNARK 非交互式地聚合在一起。而剩下的非见证数据就是对系统状态（UTXO 集合）的直接反映。虽然 SNARK 可以实现一些神奇的功能，比如直接下载一个 UTXO 集合和一个 SNARK 就从创世状态跳跃到最新状态、非交互式地将未上链交易的序列聚合为单笔交易，但我们还是需要为每一个新区块发布所有的非见证数据，以使所有的全节点都能更新他们的 UTXO 集合。因此，SNARK 无法解决区块链面临的带宽根本约束。

感谢 Sanket Kanjalkar 富有教益的讨论和评论。

（完）