解讀：zkSync究竟是宕機還是完成了一次成功的「公開練兵」？

在 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 多一點信心。

原文連結