Why Was zkSync, Which Generated Massive Transactions Due to Inscriptions, Able to Pass the Stress Test Perfectly?
TechFlow Selected TechFlow Selected
Why Was zkSync, Which Generated Massive Transactions Due to Inscriptions, Able to Pass the Stress Test Perfectly?
In the long run, the Inscription event did not, as rumored, revert Layer2 performance back to its original state; instead, it provided practical experience for further performance optimization of Layer2.
Navigating Web3 tides with focused insightsAuthor: Haotian
Introduction: The recent explosive inscription craze has served as a major stress test for various public blockchains. Some chains experienced outages, while others saw gas fees skyrocket. In this test, zkSync excelled in both performance and gas fee stability.
You might be confused—didn't zkSync go down due to inscriptions? The truth is, the perceived outage was caused by frontend display issues with blockchain explorers. This article explains, from a technical standpoint, why zkSync performs so well and why higher transaction volume actually leads to lower gas fees.
The act of minting inscriptions on zkSync, which brought a sudden flood of transactions, indeed served as a "stress test" for this Layer 2 network. However, the result was far from an outage. On the contrary, this was a public demonstration of zkSync's capabilities, and it successfully passed key benchmarks including peak TPS and gas fee stability.
At first glance, this may sound counterintuitive. Let me clarify using technical logic:
The core mechanism of zkSync’s block production can be summarized as follows: Users create transactions that enter the sequencing queue of zkSync’s Sequencer. The Sequencer then orders them by gas fee, batches them into blocks, sends the block data to the proof system for validation, and finally submits it to the mainnet for finality.
- Two aspects here easily create a false impression of “poor user experience”:
1) Transaction creation by users: Most users initiate transactions via wallets like MetaMask. When sending a transaction to zkSync through such a wallet, the transaction first enters an RPC (remote procedure call) server, then waits in the Sequencer’s queue. This queuing time can range from a few seconds to several minutes. If the wait is too long, MetaMask assumes the transaction has failed and returns a failure message.
However, this does not mean the transaction actually failed. It simply reflects a mismatch between MetaMask’s RPC timeout logic and zkSync’s Sequencer queuing mechanism. This explains why some transactions that appear failed in MetaMask later show up as confirmed when checked on the backend after some delay.
If users bypass wallets and directly call zkSync’s RPC via backend code, they avoid timeout errors and enjoy a much smoother experience. While this gives an advantage to technically skilled “power users,” it’s fundamentally a wallet UX issue—not a limitation of zkSync’s processing capacity.
2) Sequencer fairness and ordering: When users rapidly submit multiple transactions through the RPC queue, each transaction starts with a nonce value of 0 and increments sequentially. If the previous transaction is still queued (with nonce 0), and the user submits a new one (nonce 1), zkSync’s Sequencer will assign nonces based on timing and process them in order.
But if a user sees a transaction marked as failed in MetaMask and immediately submits another, due to inconsistencies between the wallet frontend and zkSync’s API, some of these new transactions may not actually reach the RPC queue. Users think they’ve submitted many transactions, but zkSync only receives a subset—though it will properly process any it does receive.
Thus, seeing a "failed" transaction in MetaMask and repeatedly resubmitting only increases the chance of actual failures—because many of those submissions never reached zkSync’s backend; users just believe they did due to frontend confusion.
Overall, the combination of MetaMask’s RPC timeout behavior and users’ impatience in resubmitting transactions creates the illusion of widespread transaction failures. Understanding zkSync’s backend workflow helps avoid these UX pitfalls.
- Clarifying the “outage” claim:
zkSync did not experience an outage—the issue was limited to frontend display problems in blockchain explorers. These explorers pull live data from zkSync’s RPC interface, but under heavy load, API responses can be delayed.
In short, the explorer’s ability to sync new data couldn’t keep up with the surge in queued transactions—an explorer frontend issue, unrelated to the chain’s actual operation. Once transaction volume stabilizes, the explorer catches up and displays accurate data.
When one explorer isn’t working, cross-verify with alternative explorers that sync zkSync data, such as: https://hyperscan.xyz
- So how is the chain actually performing?
1) Shortly after rumors of an outage spread, zkSync’s official team member Anthony Rose tweeted updates showing record-breaking TPS. In reality, zkSync reached a peak TPS of 187.9—well above its typical range of 50–100—proving it handled the traffic surge robustly. This served as valuable real-world stress testing for future scalability toward thousands or even tens of thousands of TPS.
2) The unique economics of ZK-Rollups mean that higher transaction volume leads to lower per-transaction costs. Indeed, zkSync’s gas fees actually decreased during the event, thanks to cost amortization. According to growthepie data, zkSync’s average gas price dropped by 5.2% over the past 24 hours, averaging around $0.19. Individual experiences may vary, but overall chain metrics confirm lower costs—a testament to the fact that ZK-Rollups deliver better efficiency at scale.
- What impact do inscription events have on Layer 2 networks?
According to Dune analytics, zkSync’s inscription campaign generated 5 million new transactions within 14 hours, involving 65,575 unique holders. As noted, zkSync’s team was fully aware of this community-driven “stress test” and took urgent measures to maintain orderly operations.
For zkSync, this event was a highly beneficial stress test—its positive impacts outweigh the negatives. In the long run, inscription activity didn’t expose flaws in Layer 2 performance; rather, it provided practical insights for further optimization.
That said, I’m aware other inscription projects are also emerging—though none as frenzied as zkSync’s—they’ve added additional pressure to the ecosystem.
Anyway, the overall outcome was positive. By understanding zkSync’s backend transaction ordering and clearing up misconceptions about poor UX, we can recognize that everything functioned as intended. We should give Layer 2 solutions more confidence.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Haotian | CryptoInsight
