快評Starknet升級，Starknet v0.12.0版本有哪些改進

奔走相告，@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 未來可期！

原文連結