这是我觉得非常激动人心的一个新的方向，也希望感兴趣的小伙伴可以跟我们一起去探讨这方面，探索未来充满想象力的天地。谢谢大家。

姚翔： 谢谢郭宇老师，听起来如果递归零知识证明得到更广泛地应用，那么 ZK Rollup 可以发挥更大的功能，它的效率会有更大的提升。

话筒又给到了 Steve。刚才 Steve 做了一个演讲。我也观察到 Loopring 在一季度有很大的进展，比如说增加了一个快速提款的功能，包括去提高了在 AMM 上 gas 的效率。我想问的是，请问在这个过程当中，在工程实现零知识证明上还有多少的效率可以去提升，这里面主要的难度是什么？

Steve： 其实 ZK Rollup 整个这套系统的搭建在工程角度来说还是蛮有挑战的。包括我演讲里面也说了，我们是 18 年下半年开始尝试这个方向，真正做出第一版原型系统是 19 年 3 月份，19 年底的时候才是真正的主网上线，这是第一个版本。第二个版本是在 20 年的六七月份上线，这也是半年多才迭代了一个大的版本，每前行一步，工程角度挑战都很大。

这里面尤其我可以说几个点。比如说，我们 19 年底的版本本质上还是一个不太可以商用的版本，还有很多限制，毕竟我们是第一个去尝试这条道的。比如说刚刚郭宇所提到的，默克尔树不能太大，我们当时其实就限定最多 100 万个 Layer2 的账户，那也是为了我们的默克尔树的层次不能太高，否则你去生成证明的时间开销会特别大。

第一版有很多这种工程上的权衡，但是我们后面会发现这些权衡应该要去掉。这只能从工程上去做，比如说我们在零知识证明的生成的优化上面有一篇论文，大概是提升了至少一个数量级，生成效率提高了十几倍。这之后我们就发现可以把默克尔树变得更大了，现在其实本质上是几亿个账户完全都能处理。

做完这样的一件事情之后，我们发现原来认为通过 ZK Rollup 生成零知识证明的那部分成本会很高，但是相反，现在其实生成零知识证明的成本是很低的，只是数据上链和数据在链上做验证的成本是比较高的。这部分成本怎么来进一步降低？我们其实做了很多尝试。第一个我们上传 calldata 前都是做过压缩的，甚至做了一种压缩算法，然后在 EVM 里面再解压，这样的 gas 消耗反而能更低一点。第二，我们所有二层上的交易，能节省 calldata，我们都一个字节一个字节地去抠，基本上我认为已经抠到了极致了。

所以同时就像郭宇说的，我们选了 O(1) 复杂度的 ZK-SNARK 的一个验证算法，它的验证时间不随着交易的大小增长而增长，这也是一个很大的好处。我们其实也很期待递归零知识证明最终在以太坊上能够得以实现，它能有效降低验证的时间。但是大家要记住一点，它其实不能提升整个 ZK Rollup 体系的 TPS，因为整个 ZK Rollup 最终的 TPS 限制是数据上链决定的，最大的 TPS 瓶颈就卡在这。除非你抛弃掉数据链上可用性，这是另外一条道。但我们觉得还是要保持数据上链，你的资产的安全性才得以保证。 (责任编辑：admin)