zkSync 為何能完美通過壓力測試？

2023-12-18 19:12:24

最近瘋狂的銘文運動是對各大公鏈的一次大考，有的公鏈宕機，有的公鏈手續費爆炸上漲，在這一次大考中，zkSync 無論是性能，還是GAS穩定性等都完美經受了考驗。

你或許會疑惑，zkSync 不是因為銘文宕機了么，真相是，這是由於區塊鏈瀏覽器前端顯示出現了問題，本文從技術原理的角度出發解釋了為何zkSync性能卓越，為何處理的交易量越大，Gas費則越便宜。

在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區塊數據信息的瀏覽器來交叉驗證。

-真實鏈的“運轉性能”情況如何呢？

1）在所謂宕機傳聞爆出後，zkSync的官方工作人員Anthony Rose在推特卻頻頻發出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的更流暢體驗需要將現有的用戶規模提升一個量級。