Author: @tmel0211

Original Article Link:

https://twitter.com/tmel0211/status/1736264350770643075

Engraving texts on zkSync, the short-term surge in transactions was indeed a “stress test” of layer2 public chain performance, but it didn’t result in a “crash.” On the contrary, it was an open drill for @zksync, successfully withstanding tests like peak TPS and GAS stability.

This might sound counterintuitive at first, so let me clarify with technical logic:

zkSync’s block production works as follows: Users create transactions that enter zkSync Sequencer’s sorting sequence. Sequencer then packages these based on Gas Fee, sends them to the Proof system for validation, and finally submits them to the mainnet for finality confirmation.

There are two key points that could lead to a perceived “poor experience”:

1) User transaction creation: Most users initiate transactions via wallets like Metamask. However, transactions first enter RPC remote call servers, leading to queueing time ranging from seconds to minutes. If wait time is long, Metamask might deem the transaction failed, showing a failure message.

This doesn’t mean the transaction actually failed, but rather a compatibility issue between Metamask’s RPC response time and zkSync’s Sequencer queue logic. This is why some transactions, initially shown as failed in Metamask, succeed later on.

Using backend code to directly call zkSync’s RPC avoids such timeout and failure issues, offering a smoother experience. This is more a wallet experience issue, not about zkSync chain’s processing capacity.

2) Sequencer fair sorting: When users rapidly send transactions to the RPC queue, each transaction starts with a nonce value of 0. If a new transaction (nonce=1) is initiated while the previous one is still queued (nonce=0), zkSync’s Sequencer assigns nonce based on time and sorts them accordingly.

However, if a user perceives a transaction as failed in Metamask and submits a new one, some transactions may not make it to zkSync’s backend due to wallet and zkSync API interface issues. Users might think they submitted many transactions, but zkSync only receives a portion of them.

Overall, Metamask’s RPC response logic and users hurriedly stacking transactions could lead to numerous “failures” because transactions aren’t actually submitted to zkSync’s backend.

- Clarifying the “crash” issue:

zkSync didn’t “crash.” The issue was with the browser frontend, as browsers pull data via zkSync’s RPC interface, which can be slow in responding. A surge in new transactions slows down the response.

Sponsored by NEXO. Sponsorship does not represent the views of WuBlockchain and does not constitute financial advice from WuBlockchain. Readers are requested to strictly abide by local laws and regulations.

In short, the browser’s data sync speed couldn’t keep up with the surge in queued transactions. This is a browser frontend issue, not related to the chain’s operation. Usually, once transaction speed slows, and browsers fetch new data, the issue resolves.

During browser issues, cross-verification with other browsers syncing zkSync block data, like

https://hyperscan.xyz,

can be helpful.

- How’s the real “operational performance” of the chain?

1) Amidst the so-called crash rumors, zkSync’s official

@anthonykrose

was tweeting about TPS records. In reality, zkSync’s TPS soared to a peak of 187.9, usually ranging between 50–100. This shows zkSync withstood the pressure, serving as a thorough “stress test” for future TPS in the thousands.

2) ZK-Rollup’s special mechanism means the larger the transaction volume, the cheaper the Gas fee. In fact, zkSync’s Gas fee did become cheaper, as shown by growthepie data, indicating a 5.2% decrease in the past 24 hours, averaging around $0.19. This price varies per user, but overall, it’s cheaper.

- The impact of the engraving event on layer2 public chains?

According to dune data, Sync’s engraving minting added 5M transactions in 14 hours, with 65575 holders participating. As mentioned, zkSync officials knew about this “stress test” and took measures to ensure orderly chain operation.

This was a beneficial stress test for zkSync, positively impacting more than negatively. Long-term, the engraving event doesn’t degrade layer2 performance; instead, it provides practical experience for further optimization.

However, I understand that besides Sync, other engravings are being minted. While not as FOMO-inducing as Sync, they also contribute to the stress test.

Anyway, the overall result is positive. Understanding zkSync’s backend sorting and block production logic and clearing up the “poor experience” misconception should reassure everyone that all is running well. We should have more confidence in layer2.

Follow us
Twitter: https://twitter.com/WuBlockchain
Telegram: https://t.me/wublockchainenglish