Why can Layer2 zkSync handle massive transaction pressure?

What makes Layer2 zkSync capable of managing high transaction volume?

Author: Haotian, Cryptocurrency Observer Source: X, @tmel0211

Engraving on the zkSync chain, the influx of massive transactions in a short period of time is indeed a “stress test” for layer2 public chain performance. However, the result is not a “crash”, on the contrary, this is a public training of zkSync, and the results have successfully passed the test of TPS peak and GAS stability.

At first glance, it may seem counterintuitive. Next, I will clarify it for everyone using technical logic:

The working principle of zkSync block packaging is simple: users construct transactions and enter the zkSync Sequencer sorting sequence, and then the Sequencer packs the transactions into blocks according to the order of Gas Fee, and then passes the blocks to the Proof system for verification, and finally submits them to the main network for finality confirmation.

• FTX Drops the Mic Unveils Epic Blueprint to Shower Billions Upon Customers and Creditors, Kicking Off Blockbuster Finale for Bankruptcy Recovery
• Sui Overview Technical Features and Current Status of Ecological Development
• 48 Countries Pledge to Implement CARF Attitudes of Parties and Future of Transparent Cryptocurrency Tax Framework

There are 2 key points here that can easily create the illusion of “poor experience”:

1) User transaction construction process: Most users will initiate transactions through wallets such as Metamask, and when transactions are sent from the wallet side to zkSync, the transaction will first enter the RPC remote call server, and then the Sequencer will receive these transactions and enter the queuing sequence. The queuing time here can be a few seconds or a few minutes. If the waiting time is too long, MetaMask will consider the transaction as failed, and the front end will return a transaction failure prompt.

However, this does not mean that the transaction has actually failed, but it is only due to the “incompatibility” between the RPC response time and feedback logic of MetaMask and the queuing and packaging transaction logic of zkSync’s Sequencer. This is exactly why some transactions that are displayed as failed by MetaMask will show success after a period of time.

If users do not use wallet channels and directly call zkSync’s RPC using backend code, there will be no problem with response time timeout and failure prompt, and the experience will be relatively smooth. This does give some advantage to “scientists” who can use backend code instructions, but fundamentally, it is a problem with wallet experience and has nothing to do with the processing capacity of the zkSync chain.

2) Fair sorting of Sequencer: When users send transactions to the RPC queue for a short period of time, each transaction will start from nonce 0. If the previous transaction is still in the queuing state with nonce 0, and the user initiates a new transaction with nonce 1, zkSync’s Sequencer will assign a nonce to these transactions based on time, and then sort them in order.

However, if the user sees a failed transaction on the MetaMask front end and at the same time submits a new transaction, due to the issues with the wallet side and zkSync API interface call, some of the new transactions may not be successfully submitted to the RPC queue. The user may think that they have submitted many transactions, but in reality, zkSync has only received a portion of them, and as long as they receive them, they will be sorted and processed.

From this perspective, the behavior of repeatedly submitting new transactions when seeing MetaMask feedback of transaction failure will also cause a large number of transactions to “fail” because they haven’t been submitted to the backend of zkSync chain, even though you think you have submitted them on the front end.

All in all, the RPC response time logic problem of the MetaMask wallet and the behavior of users hastily stacking transactions on the chain can both cause a large number of transactions to “fail”. If you understand the backend transaction processing workflow of zkSync, it will be relatively easier to avoid these optimization experience issues.

Based on the above introduction, let’s clarify the issue of “downtime”:

The zkSync chain did not “crash”, it was just a display issue with the browser frontend. The browser pulls the latest data from zkSync’s RPC interface, but there could be delays in the response due to a large number of new transactions.

In short, the synchronization speed of the browser’s data retrieval cannot keep up with the rapid increase in queued transactions. This is a frontend issue and has nothing to do with the operation of the chain. Usually, when transaction speed slows down appropriately and the browser is able to fetch new data, the problem will be resolved.

When the browser is not working, you can cross-verify the zkSync block data information through other browsers that sync with zkSync, such as: https://hyperscan.xyz

How is the real chain’s “performance”?

1) After the rumored crash, Anthony Rose, an official zkSync team member, frequently tweeted about TPS (transactions per second) records. In fact, zkSync’s TPS peaked at 187.9, while under normal circumstances, it is only around 50-100 TPS. This indicates that zkSync actually withstood the pressure from a large influx of new transactions. This can be seen as a comprehensive “stress test” for future thousands or even tens of thousands of TPS.

2) The special mechanism of ZK-Rollup determines that the larger the volume of transactions processed, the cheaper the gas fee. In fact, zkSync’s gas fee has become cheaper because the transaction costs have also been shared. According to growthepie data, in the past 24 hours, zkSync’s average gas fee has decreased by 5.2%, averaging around $0.19. Individual experiences may vary, but overall, the running data of the chain indeed shows a decrease in gas fees. This confirms the smoother experience of ZK-Rollup, which requires an increase in the existing user base by an order of magnitude.

What is the impact of the Mingwen incident on Layer 2 public chains?

According to data from Dune Analytics, there were 5 million new transactions in Sync’s Mingwen forging within 14 hours, with a total of 65,575 holders participating. As mentioned above, zkSync officials are already aware of this “stress test” initiated by the community and have taken emergency measures to ensure the orderly operation of the zkSync chain.

For zkSync, this data is indeed a good stress test experiment, with positive effects outweighing the negative. In the long run, the Mingwen incident did not bring Layer 2’s performance back to the prototype, but rather provided practical experience for further performance optimization of Layer 2.

However, from what I understand, besides Sync, there are other Mingwen being forged as well. Although it is not as popular as Sync, it has also added fuel to this stress test.

Anyway, the overall result is good. If we can understand the technical logic behind zkSync’s backend block sorting and dispel the “poor user experience” misunderstandings, then we should know that everything is running smoothly, and we should have more confidence in Layer 2.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!