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

原文作者:@tmel0211

原文来源:Twitter

注:原文来自@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,但硬件性能不能无脑强堆,得综合考虑成本以及性能利用率等问题,是个需要权衡的问题。

转载声明:本文 由CoinON抓取收录,观点仅代表作者本人,不代表CoinON资讯立场,CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据,请自行承担全部责任。

声明:图文来源于网络,如有侵权请联系删除

风险提示:投资有风险,入市需谨慎。本资讯不作为投资理财建议。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 2023年8月9日 下午4:33
下一篇 2023年8月9日 下午4:33

相关推荐

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

星期三 2023-08-09 16:33:02

注:原文来自@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,但硬件性能不能无脑强堆,得综合考虑成本以及性能利用率等问题,是个需要权衡的问题。