长推：zkSync CEO 罕见回应 ZK-Rollup 发展瓶颈问题

注：原文来自@tmel0211发布长推。

看了Epicenter Podcast一期采访 @zksync CEO @gluk64 的内容，罕见地谈到了 ZK-Rollup的bottleneck瓶颈问题，基于个人理解总结下：

1）Speed of Sequencer （TPS）：Sequencer负责交易排序，它的处理能力决定了链的TPS，目前单一Sequencer处理能力大约几百txs左右，要扩大TPS有两种路径，要么继续提高单个Sequencer的能力，这样会中心化，要么引入更多Sequencer，虽然去中心化了，但是协调起来会增加延迟降低TPS，这是一个需要权衡的问题。

zkSync目前计划还是在推荐去中心化Sequencer进程；而且ZK Stack这种把组件模块化的方式，长期来看可以减缓这个矛盾，因为只有极小部分的组件会被依赖，大部分都是可选择可定制的。

2）Data availability（数据可验证性）：zkSync目前把所有的input数据都放在了链上，以确保可获取和验证性，这就是data availability，之前的Thread提过zkSync的Flowworks是二次提交验证机制，也就是说，Sequencer排序好交易的第一阶段，zkSync要把输入数据的哈希存放到以太坊主网上，之后开始第二阶段，先经由zkPorter生成 SNARK证明，再走Prover ZK电路验证，最后提交给主网的Rollup合约验证。两次的数据会做一个最终的匹配性校验，完成后才算一次成功的zk proof过程。

但问题是，以太坊的Block本身有容量瓶颈，将来zkSync的数据规模大到一定程度，不一定全部数据都会上主链，得引入 external data的验证，这样的话得转化目前的二次验证方式，减少对主网数据的依赖，那如何确保安全性就成了一个瓶颈；zkSync要往STARK转型有一部分因素也是这个，相比SNARK，STARK更适合使用外部的可验证数据。

3）ZK circuit hardware（ZK 电路硬件性能）：SNARK证明是一种复杂的证明电路系统，构建电路需要消耗大量的计算机内存，目前SNARK证明要消耗6-16GB的RAM空间，若电路更大其消耗的内存资源也会同步增长，因此硬件问题也是个瓶颈。要解决这个问题，可以通过优化算法来解决，或者采用更高级的定制硬件，目前高端的工作站可达到TB级别的RAM，但硬件性能不能无脑强堆，得综合考虑成本以及性能利用率等问题，是个需要权衡的问题。