Starknet 升级:一次杀死 pending 的亲民化更新
Haotian
2023-07-13 09:02
订阅此专栏
收藏此文章
直接感官体验是交易速度从 10-20 分钟缩短到了数秒级。


撰文:Haotian


奔走相告, @Starknet v0.12.0 杀死 Pending 的升级成功了!直接感官体验,交易速度从 10-20min 缩短到数秒级了,Starknet 终终终终于注重用户体验了。


那么,从技术视角该如何看待 Starknet 的这次升级呢?和 zkSync 相比,How it works?这会对 Starknet 的后续生态发展带来哪些影响?来,探讨下。


论 zk 技术 starknet 优于 zkSync,但 zkSync 的主网交互地址、生态繁荣度、TVL 等 Metrics 数据都远超 Starknet。why?


原因是 Starknet 在账户抽象、Pending 等用户感官层面体验糟糕。


此次升级优化了 cario 合约算法,重写了 Sequencer,增加了 TPS,关键后置了 accepted on L1 的时间,大大缩短了交易「成功」时间。


也就是说,原先用户端要等待 txs 被 L1 验证成功后才结束 pending 状态,时间大概 20min,现在只要在 L2 上生成 Stark 证明后就先默认 txs 成功了,时间数秒即可。


但相应的,Accepted on L1 的时间也被加到了 5 小时以上(如下图),这主要是为了确保分层确定性机制的网络安全问题,避免 L1 出现重组的概率。


原先的单层确认机制,虽然 pending 时间长,但只是感官问题,用户在存在 pending 交易的情况下再发其他交易也是可以的。(撸 er 加不加号症结不在此)


只不过用户习惯了等待一笔交易完成后再开始新交易。但消灭 pending 后会带动 txs 的高频巨量。


为确保足够安全,L1 确认的时长被大幅增加,反正用户无感知。


ow it works?zkSync 采用二阶段提交验证机制,在 Snark 证明生成后和被验证后会和 L1 交互 2 次,而 starknet 是单阶段验证,只向 L1 提交最终状态,而不是最初的提交状态。


那如何确保状态变化前后一致呢?这其实是 Stark 证明强大于 Snark 证明的一点,Stark 证明可以基于最终状态推导出提交状态自我校验。


一方面,Starknet 在算法和计算资源上产生更大消耗;另一方面 Starknet 会堆砌更多的交易在其 cario contract 上,对其 zk 电路算法的考验尤为大。交易多则状态推导压力大,一旦个别错误,就可能导致网络拥堵。


这也就解释了,为啥 Accepted on L1 的时间会超过 5 小时。主要在给其 zk 算法争取更多容错时间。


整体而言,Starknet 的升级战略意义显著,它将 Starknet 亲民化,将直接带动其各项数据提升,改变 L2 各公链竞争局势。


但你一定得知道,前端体验简化的代价一定是后端技术加码,后续 Starknet 面临的网络稳定性挑战一定不小。


不过,弥补了不够贴近市场和用户的生态短板,friendly 的 Starknet 未来可期!

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

Haotian
数据请求中
查看更多

推荐专栏

数据请求中
在 App 打开