ZKSync 产品与生态:灵活组装的扩容捷径_SYN:SYNC币

作者:echo_z,链茶馆

随着Optimism发币、Arbitrum开启Odyssey羊毛大战,2022年下半年注定是L2百花齐放的阶段。此前,链茶馆已撰文详述过L2的背景及ZK系的StarkWare专项介绍,而作为ZK系的另一个代表项目,ZKSync也值得关注。本文将在与StarkWare对比的框架下,深度解析ZKSync的产品架构及运营生态。

一:产品体系

ZKSync的产品早已有之,但在1.0阶段,仅仅支持支付等简单功能;到2.0产品实现了EVM兼容,开始发挥其真正实力。

ZKSync2.0在去年6月上线测试网,但没有向开发者开放;去年10月上线第一款zkEVM产品UniSync,也就是Uniswap在ZKSync的版本;直到今年2月,终于向开发者开放了ZKSync2.0开发工具,开始部署生态。目前ZKSync主网产品仍然在1.0阶段。本文将重点围绕2.0进行介绍。

1.1证明系统:SNARKvsSTARK

ZKSync与StarkWare在最底层所选择的证明系统不同,ZKSync选择的是较为成熟的SNARK技术,而StarkWare则是自研的STARK系统。底层技术的差异,也使得二者的性能潜力、产品路线图迥然。

业界对于这两种证明系统的共识是:在计算量较大的情况下,STARK的可扩展性和速度会明显胜过SNARK,而且STARK更安全。

在可扩展性和速度方面,STARK能够生成包含更多计算结果的证明。虽然STARK所需要的字节数更多、验证也需要更长的时间,但是更大的证明本身能够使得每笔交易所分摊的gas更低。

数据:zkSync Era 链上独立地址数突破 100 万:6月30日消息,据 Dune 数据显示,zkSync Era 链上独立地址数已突破 100 万,现为 1,086,771 个,链上桥接 TVL 总额达到 562,299 枚 ETH。据欧科云链 OKLink 多链浏览器数据显示,当前 zkSync Era 链上地址总数为 2,846,469 个,总交易量约 423 万笔。[2023/6/30 22:10:55]

在安全性方面,SNARK必须要有受信的初始化,有一定的信任前提,而STARK则不需要这个前提。

1.2数据可用性模式:颗粒度不同的混合模式Volition

数据可用性,简单解释其含义为,除了交易更新完的最终状态数据之外、用于复原交易历史的其他相关信息,是否能被获取。如果这些必要数据都放在链上,就是Rollup模式,安全级别更高、同时也因为消耗了更多链上存储空间而更昂贵;如果放在链下就是Validium模式。数据可用性模式的选择,本质上是安全性和效率之间的取舍。

在这一点上,StarkWare和ZKSync都采取了「Volition」模式,即Rollup和Validium的混合,用户可以自主选择用哪种方式来存储数据。

来源:https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb

zkSync生态项目Snark表示将退回超募ETH:4月13日消息,zkSync 生态项目 Snark 在其社交平台表示,将退回 Launchpad 期间超募的 ETH。项目方在公告中表示,此前由于合约设置错误,导致项目 Launchpad 期间共募集 499 ETH,超出原计划硬顶(220 ETH),因此决定退回超募的 279 枚 ETH。

团队表示目前正在统计相关数据,预计 4 月 16 日至 17 日完成退款。[2023/4/13 14:01:17]

Volition的设想最早由StarkWare提出,上图出自其2020年发布的博客。不过到目前为止,StarkWare和ZKSync都还没有将Volition落地。但是在ZKSync的路线图中,似乎对这一功能设计更为重视,专门命名为ZKPorter,并且将ZKPoter和zkEVM并列为两大架构上的突破。

值得注意的是,StarkWare和ZKSync对于用户可选择的「颗粒度」设定是不同的。StarkWare选择的颗粒度更细,实现难度也更大。

StarkWare的设想中,用户将会以「每笔交易」为单位,自主选择数据可用性模式。但这样可能会带来一个问题:当用户的同一个账户,同时选择这两种模式时,如果安全级别更低的Validium交易出现了问题,那在这笔交易之后出现的Rollup交易是否也会受到影响?按照StarkWare的早期设想,为了防止数据不可用性的攻击,设计了最小回滚机制,即如果检测到有数据不可用,就会将交易历史回滚至上一个数据可用的区块状态。在最坏的情况下,最小回滚机制可能会要求所有数据都发布在链上,其实又回到了Rollup模式。相关细节还未公布,但可以想见难题不少。

数据:zkSync Era提交区块数量突破100万:金色财经报道,据zkSync Era链上数据显示,当前提交区块数量已突破100万,本文撰写时达到1,001,636,其中已验证区块数量为932,956个,链上交易总量达到5,104,679笔。另据l2beat数据显示,zkSync Era锁仓量为1.56亿美元,涨幅98.52%。[2023/4/8 13:50:52]

而在ZKSync的设计中,用户将以「账户」为单位,选择数据可用性模式。也就是说,Rollup账户的交易都将以Rollupo模式进行,ZKPoter账户的冗余数据则都会放在链下。如此一来,两种模式下的交易其实是隔离的,各有各的交易历史,不会相互影响。不过,ZKSync也会允许zkRollup和ZKPoter的账户之间进行互操作,猜测这样的交易会同时记录在zkRollup和zkPorter中,保证安全性。

来源:https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf

1.3开发语言:原生语言CairovsSolidity优先策略

StarkWare在很长一段时间内都以原生语言Cairo作为唯一的开发语言。Cairo也是StarkWare团队自研的语言,能够很好地适配STARK证明系统,但由于要求开发者学习新的语言,造成了进入门槛高的问题。

在兼容EVM方面,StarkWare的解决方案是由第三方团队Nethermind开发Solidity到Cairo的编译器Warp。Warp1.0版本由于生成的Cairo文件过大,普及率并不高,但Warp2.0版本借助了Yul,大幅提升了效率。就在本月,Warp2.0开始进入审计,即将投入使用。

zkSync发布生态进展更新:Celer Network已与zkSync 2.0测试网集成:11月21日消息,zkSync 发布生态系统的五个最新进展,包括跨链基础设施 Celer Network 已经与 zkSync 2.0 测试网集成,确认在 zkSync 的公平启动 Alpha 里程碑中增加了资产桥接和消息传递。MUX Protocol 的多链原生 DeFi 协议现已在 zkSync 2.0 测试网上运行。Pocket Network 确认其激励节点运行器网络即将进入 zkSync 生态系统。depocket.com 宣布其用户可以在其 DeFi 仪表板产品上跟踪 zkSync 的质押余额。BlockWallet 详细介绍了他们在零妥协 Web3 钱包中对 zkSync 2.0 测试网的支持的持续改进。[2022/11/22 7:53:49]

ZKSync则在更早以前就采取了Solidity优先的策略,ZKSync2.0上线时就允许开发者用Solidity编写合约。其实现方式如下图所示:以LLVM作为编译器后台,通过Yul将Solidity编译到LLVM,再编译到zkEVM。这样做的好处在于,未来其他语言也可通过类似的方式来实现兼容。ZKSync目前的开发和维护集中在Solidity语言上,未来将开发自研的语言Zinc、开放Rust等语言的兼容。

来源:https://blog.matter-labs.io/zksync-2-0-hello-ethereum-ca48588de179

zkSync桥接存储总价值突破18万枚ETH:11月20日消息,Dune数据显示,以太坊Layer2扩容解决方案zkSync跨链桥接存储总价值已突破18万枚ETH,目前为181,661 ETH(按照当前ETH价格计算约合2.2亿美元),参与桥接交易的用户量为466,026个。[2022/11/20 22:10:20]

ZKSync的策略对开发者来说无疑降低了进入门槛,通过EVM兼容来快速吸引生态项目、沉淀TVL是其核心目标。但是鉴于StarkWare的编译器Warp2.0即将上线,预期同样能够吸引Solidity开发者,ZKSync的发展很有可能会受到影响。

1.4整体架构:均以Sequencer和Prover为核心

整条网络的核心架构,将会决定网络以怎样的方式来实现去中心化。整体上,二者都将以Sequencer和Prover作为架构的核心。Sequencer的核心作用包括:挑选有效交易并执行计算,而Prover则将为计算结果生成证明。

StarkWare还未明确Sequencer和Prover的角色会分开还是合并,而ZKSync则已经将Sequencer的角色称为「全节点」,推测和Prover将会是独立的实体。此外,ZKSync的架构中还增加了交互器以辅助L2和L1的交互、计算手续费等,以及偏执监视器来做健康监控。

如何实现去中心化,从长远来看非常重要,但这一课题对于发展较为初期的ZKRollups来说,还是下一步的问题,目前StarkWare和ZKSync都还没有非常明确的答案。

1.5小结

本节从证明系统、数据可用性模式、开发语言和整体架构对比了StarkWare和ZKSync。除了整体架构方面,二者的核心角色类似、细节尚不明确外,其他方面都有不小的差异。

在证明系统方面,StarkWare采取的STARK比ZKSync采取的SNARK具有更强的可扩展性和安全性;在数据可用性模式方面,二者都提供了用户可自主选择的Volition,但ZKSync将以账户为单位,而StarkWare以每笔交易为单位,ZKSync的颗粒度更粗、路径也更简单;在开发语言方面,StarkWare优先开发了原生语言Cairo,随后通过第三方公司开发的编译器实现EVM兼容,而ZKSync则在最开始就采取了Solidity优先的策略,对开发者门槛更低,但现在依然面临StarkWare的强力竞争。

总体而言,ZKSync的路线更「亲民」,产品也更类似苹果的组装模式,核心技术如SNARK、LLVM等均来自业界或学界的已有成果;相对来看,StarkWare则更硬核,不论在技术还是产品层面,都选择了更难的原创路线。

二:运营生态

ZKSync的生态项目集中在Defi和基础设施方面。

在ZKSync的官网,可以看到正在迁移到ZKSync2.0的成熟项目,Defi类包括1inch、FRAX、Zigzag等;基础设施类包括GnosisSafe、Snapshot等、跨链桥如Orbit、中心化交易所如Banxa。

来源:https://ecosystem.zksync.io/

在其notion页面则罗列了即将或已经部署在ZKSync2.0的新兴项目。其中,TrustlessCurrencyProtocol是一个类似Maker的抵押借贷项目,SyncSwap是一个类似Uniswap的代币兑换DEX。MintSquare是一个基于ZKRollups建立的NFT市场,也在StarkNet测试网上进行了部署,tofuNFT则是一个多链NFT市场,在BNB、ETH、Arb等多条链上均已部署。

来源:https://matterlabs.notion.site/zkSync-2-0-Testnet-Applications-e38328bccda7472793024a25e26a1cac

整体而言,ZKSync2.0的生态主要来源于成熟Defi及基础设施项目的迁移、多链NFT市场的部署,除此之外似乎还没有令人眼前一亮的项目。对比来看,StarkNet测试网上有诸多游戏项目、以及StarkNet原生的Defi项目,从品类上比ZKSync要更丰富且独立。

三:团队及融资

MatterLabs联创及CEOAlexGluchowski来自德国,2011年毕业于柏林工业大学,获得硕士学位。其后,曾在多家公司担任研发/CTO等职位。2013年开始创业,联合创办过健身平台SomuchmoreGmbH、野营车租赁平台PaulCamper。2017年9月,进入香港的EntropyLabs担任研发,从此开始进入区块链行业。2018年年末,联合创办MatterLabs。

另一位联创AlexandrVlasov的经历相对简单,2006~2012年就读于莫斯科国立大学,专业为核与粒子物理学,2013~2018年就读于加拿大的麦吉尔大学,获得电子工程博士学位,随后就加入了MatterLabs主管研发。

截止目前MatterLabs总融资额度5,800万美元,其中5,000万美元均来自2021年11月的B轮融资,由a16z领投。a16z也投资了Optimism,同时押注OP系和ZK系。

对比来看,StarkWare曾有过ZCash的加密行业成功经验、团队以教授领头,且已经获得~2.8亿美元融资,ZKSync的团队和融资相对草根。

四:优势及挑战

ZKSync的风格有些类似苹果,善于将成熟技术组装成用户可用的新产品,以Solidity为优先的策略也对开发者非常友好。对于ZKSync来说,现有的zkEVM能否迅速吸引L1上的已有成熟应用、将TVL做高,会是一个关键。这或许也是ZKSync希望在L2之争中占有一席之地的捷径之路。

然而在这一方面,ZKSync面临多方面竞争:OP系的Optimism已经发币,能够通过代币激励来吸引用户,而Arbitrum近日也已经开启Odyssey活动,通过营销活动来吸引用户和资金;一直以来基于原生语言Cairo、生态较为独立的StarkWare,也即将上线升级版的Solidity编译器,降低了开发者进入门槛。在这一场L2之争中,ZKSync的速度将至关重要。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

水星链

[0:15ms0-0:881ms