长推:zkSync链上刻铭文是一次完美的公开练兵

Anthonykrose在推特上发出zkSync TPS飙到187.9的消息,证明zkSync的运转性能良好,这也是一次充分的“压力测试”。ZK-Rollup的特殊机制决定了Gas费越大,Gas费也越便宜,zkSync的Gas费确实更加便宜了。铭文事件对layer2公链的影响,zkSync官方采取措施确保链的有序运行,给layer2的性能优化提供了实践经验,结果总体而言是好的。

摘要由 Mars AI 生成

本摘要由 Mars AI 模型生成,其生成内容的准确性、完整性还处于迭代更新阶段。

注:本文来自@tmel0211 推特,火星财经整理如下:

zkSync 2.0

在zkSync链上刻铭文,短时涌入的天量交易,确实是一次layer2公链性能的“压力测试”,不过结果并非“宕机”,恰恰相反,这是一次 @zksync 的公开练兵,结果是TPS峰值、GAS稳定性等都完美经受了考验。

乍一听,是不是有点反直觉?接下来,用技术逻辑,我来给大家澄清一下:

zkSync打包出块的工作原理,简单而言:用户构造交易进入zkSync Sequencer的排序序列,然后Sequencer根据Gas Fee高低排序打包进区块,然后再把区块传入Proof系统验证,最后Submit到主网完成finality状态确认。

-这里边有2个关键点,容易制造“体验糟糕”假象:

1)用户构造交易环节:大部分用户都会通过Metamask等钱包端发起交易,而通过钱包端向zkSync发交易,交易会先进入RPC远程调用服务器里,然后Sequencer接收这些交易进入排队序列。这里的排队时间短则几秒,长则几分钟,人如果等待时间较长,MetaMask就会认定该笔交易已经失败,然后前端返回交易失败的提示。

然而,这并不意味着交易真失败了,而只是因为Metamask的RPC响应时间和反馈逻辑和zkSync的Sequencer排队打包交易逻辑存在“不兼容”所致。这正是为何,一些明明MetaMask显示失败的交易,在等待一段时间后,后端服务器显示又成功的原因。

如果用户不走钱包管道,直接使用后端代码调用zkSync的RPC,就不会存在响应时间超时以及提示失败的问题,体验相对而言会很丝滑。这确实会让一些可使用后端代码指令的“科学家”取得了优势,但本质上属于钱包体验端的问题,和zkSync链的处理能力无关。

2)Sequencer公平排序环节:当用户短时向RPC队列发出交易时,每一笔交易都会从nonce值为0开始叠加,如果上一笔交易还在排队状态,nonce为0,这时用户又发起了一笔新交易nonce为1,zkSync的Sequencer会根据time来给这些交易分配nonce,然后按照顺序排序。

但倘若,用户在MetaMask前段看到上一笔交易显示失败后,同时又提交新的交易,很可能新提交的交易由于钱包端和zkSync API接口调用的问题,有一部分交易最终并没有成功提交到RPC的排队序列中。用户以为提交了很多交易,实际上zkSync只收到了其中一部分,而只要他们收到就会去排序处理。

这么看,用户看到MetaMask反馈交易失败,不停提交新交易的行为也会造成大量交易失败,因为根本就没有提交到zkSync链的后端,只是你在前端以为自己提交了。

整体而言,MetaMask钱包的RPC响应时间逻辑问题和用户着急向链上叠加交易的行为,都会造成大量的交易“失败”,如果清楚zkSync的后台交易处理工作流程的话,相对更容易避开这些优化体验问题。

-基于以上科普,再来澄清下“宕机”问题:

zkSync链并未“宕机”,只是浏览器前端显示问题,因为浏览器会通过zkSync的RPC接口拉取最新数据,但是接口响应会有延迟,大量新交易会使响应变慢。

总之,浏览器的拉取数据同步速度跟不上排队交易激增的速度,这是浏览器前端的问题,与链的运转没有关系。通常等交易速度适当放缓,浏览器可以抓取到新数据后,问题就会解决。

当遇到浏览器不work的时候,可以通过其他同步zkSync区块数据信息的浏览器来交叉验证,比如: https://hyperscan.xyz

-真实链的“运转性能”情况如何呢?

1)在所谓宕机传闻爆出后,zkSync的官方工作人员 @anthonykrose 在推特却频频发出TPS刷新捷报。实际上,zkSync TPS飙到了187.9的峰值,正常情况下,TPS只有50-100左右,这说明大量的新交易涌入,zkSync其实抗住了压力。这确实也给未来数千甚至上万的TPS做了一次充分的“压力测试”。

2)ZK-Rollup的特殊机制决定了,处理的交易量越大,Gas费则越便宜,事实上,zkSync的Gas费确实更加便宜了,因为交易成本也被分摊了,根据growthepie数据显示,近24小时,zkSync的Gas平均值还降低了5.2%,平均在$0.19左右,这个数据每个人的体验可能不一样,但综合链的运行数据,确实是便宜了。佐证了ZK-Rollup的更流畅体验需要将现有的用户规模提升一个量级。

-铭文事件对layer2公链的影响?

根据dune数据显示, Sync的铭文铸造,14个小时新增了5M笔交易,已有65575个Holder参加。诚如上述所言,zkSync官方已经知道了这场社区发起的“压力测试”活动,还紧急采取措施来确保zkSync链的有序进行。

这个数据对zkSync而言确实是一次较好的压力测试实验,其正向影响大于负面。长远看,铭文事件并非传言中把layer2性能打回了原型,反倒给layer2的进一步性能优化提供了实践经验。

不过据我了解,除了Sync之外,还有其他铭文正在铸造,虽不及Sync那么fomo,但也给此压力测试添了一把火。

Anyway,结果总体而言是好的,大家若厘清zkSync后台排序出块的技术逻辑,再拨开其中存在的“体验糟糕”误会,就应该懂得,一切运行安好,我们得给layer2多一点信心。

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

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

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

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 2023年12月18日 下午12:45
下一篇 2023年12月18日 下午12:45

相关推荐

长推:zkSync链上刻铭文是一次完美的公开练兵

星期一 2023-12-18 12:45:46

注:本文来自@tmel0211 推特,火星财经整理如下:

zkSync 2.0

在zkSync链上刻铭文,短时涌入的天量交易,确实是一次layer2公链性能的“压力测试”,不过结果并非“宕机”,恰恰相反,这是一次 @zksync 的公开练兵,结果是TPS峰值、GAS稳定性等都完美经受了考验。

乍一听,是不是有点反直觉?接下来,用技术逻辑,我来给大家澄清一下:

zkSync打包出块的工作原理,简单而言:用户构造交易进入zkSync Sequencer的排序序列,然后Sequencer根据Gas Fee高低排序打包进区块,然后再把区块传入Proof系统验证,最后Submit到主网完成finality状态确认。

-这里边有2个关键点,容易制造“体验糟糕”假象:

1)用户构造交易环节:大部分用户都会通过Metamask等钱包端发起交易,而通过钱包端向zkSync发交易,交易会先进入RPC远程调用服务器里,然后Sequencer接收这些交易进入排队序列。这里的排队时间短则几秒,长则几分钟,人如果等待时间较长,MetaMask就会认定该笔交易已经失败,然后前端返回交易失败的提示。

然而,这并不意味着交易真失败了,而只是因为Metamask的RPC响应时间和反馈逻辑和zkSync的Sequencer排队打包交易逻辑存在“不兼容”所致。这正是为何,一些明明MetaMask显示失败的交易,在等待一段时间后,后端服务器显示又成功的原因。

如果用户不走钱包管道,直接使用后端代码调用zkSync的RPC,就不会存在响应时间超时以及提示失败的问题,体验相对而言会很丝滑。这确实会让一些可使用后端代码指令的“科学家”取得了优势,但本质上属于钱包体验端的问题,和zkSync链的处理能力无关。

2)Sequencer公平排序环节:当用户短时向RPC队列发出交易时,每一笔交易都会从nonce值为0开始叠加,如果上一笔交易还在排队状态,nonce为0,这时用户又发起了一笔新交易nonce为1,zkSync的Sequencer会根据time来给这些交易分配nonce,然后按照顺序排序。

但倘若,用户在MetaMask前段看到上一笔交易显示失败后,同时又提交新的交易,很可能新提交的交易由于钱包端和zkSync API接口调用的问题,有一部分交易最终并没有成功提交到RPC的排队序列中。用户以为提交了很多交易,实际上zkSync只收到了其中一部分,而只要他们收到就会去排序处理。

这么看,用户看到MetaMask反馈交易失败,不停提交新交易的行为也会造成大量交易失败,因为根本就没有提交到zkSync链的后端,只是你在前端以为自己提交了。

整体而言,MetaMask钱包的RPC响应时间逻辑问题和用户着急向链上叠加交易的行为,都会造成大量的交易“失败”,如果清楚zkSync的后台交易处理工作流程的话,相对更容易避开这些优化体验问题。

-基于以上科普,再来澄清下“宕机”问题:

zkSync链并未“宕机”,只是浏览器前端显示问题,因为浏览器会通过zkSync的RPC接口拉取最新数据,但是接口响应会有延迟,大量新交易会使响应变慢。

总之,浏览器的拉取数据同步速度跟不上排队交易激增的速度,这是浏览器前端的问题,与链的运转没有关系。通常等交易速度适当放缓,浏览器可以抓取到新数据后,问题就会解决。

当遇到浏览器不work的时候,可以通过其他同步zkSync区块数据信息的浏览器来交叉验证,比如: https://hyperscan.xyz

-真实链的“运转性能”情况如何呢?

1)在所谓宕机传闻爆出后,zkSync的官方工作人员 @anthonykrose 在推特却频频发出TPS刷新捷报。实际上,zkSync TPS飙到了187.9的峰值,正常情况下,TPS只有50-100左右,这说明大量的新交易涌入,zkSync其实抗住了压力。这确实也给未来数千甚至上万的TPS做了一次充分的“压力测试”。

2)ZK-Rollup的特殊机制决定了,处理的交易量越大,Gas费则越便宜,事实上,zkSync的Gas费确实更加便宜了,因为交易成本也被分摊了,根据growthepie数据显示,近24小时,zkSync的Gas平均值还降低了5.2%,平均在$0.19左右,这个数据每个人的体验可能不一样,但综合链的运行数据,确实是便宜了。佐证了ZK-Rollup的更流畅体验需要将现有的用户规模提升一个量级。

-铭文事件对layer2公链的影响?

根据dune数据显示, Sync的铭文铸造,14个小时新增了5M笔交易,已有65575个Holder参加。诚如上述所言,zkSync官方已经知道了这场社区发起的“压力测试”活动,还紧急采取措施来确保zkSync链的有序进行。

这个数据对zkSync而言确实是一次较好的压力测试实验,其正向影响大于负面。长远看,铭文事件并非传言中把layer2性能打回了原型,反倒给layer2的进一步性能优化提供了实践经验。

不过据我了解,除了Sync之外,还有其他铭文正在铸造,虽不及Sync那么fomo,但也给此压力测试添了一把火。

Anyway,结果总体而言是好的,大家若厘清zkSync后台排序出块的技术逻辑,再拨开其中存在的“体验糟糕”误会,就应该懂得,一切运行安好,我们得给layer2多一点信心。