Under the inscription stress test, zkSync completed a successful public training
Original author: Haotian (X: @tmel0211)
Editors note: The Inscription track is still hot, and a huge amount of transactions flooded into the zkSync chain in a short period of time. In this stress test, zkSync went down because of Inscription? Or has perfection been tested? crypto researcherHaotian(X: @tmel0211) From the technical logic, we have clarified the illusion and misunderstanding of zkSync’s “bad experience”. Odaily summarized it as follows:
Engraving inscriptions on the zkSync chain and the huge amount of transactions that poured in in a short period of time were indeed a stress test for the performance of the Layer 2 public chain, but the result was not downtime, on the contrary.This is a public training exercise by @zksync, and the result is that TPS peak value, GAS stability, etc. have all been tested perfectly.
At first glance, does it sound counter-intuitive? Next, let me clarify it for you using technical logic:
The working principle of zkSync packaging block production, in simple terms:The user constructs the transaction and enters the zkSync Sequencers sorting sequence, and then the Sequencer sorts and packages it into blocks according to the Gas Fee, and then passes the block to the Proof system for verification, and finally submits to the main network to complete the finality status confirmation.
-There are two key points here that can easily create the illusion of a bad experience:
1) User constructs transaction link:Most users will initiate transactions through wallets such as Metamask, and send transactions to zkSync through the wallet. The transactions will first enter the RPC remote call server, and then the Sequencer will receive these transactions and enter the queue sequence. The queuing time here can be as short as a few seconds or as long as a few minutes. If a person waits for a long time, MetaMask will determine that the transaction has failed, and then the front end will return a prompt that the transaction failed.
However, this does not mean that the transaction actually failed;This is due to the incompatibility between Metamasks RPC response time and feedback logic and zkSyncs Sequencer queuing and packaging transaction logic.This is exactly the reason why some transactions that MetaMask clearly shows failed, after waiting for a period of time, the backend server shows success again.
If users do not go through the wallet pipeline and directly use the back-end code to call zkSyncs RPC, there will be no problem of response time timeout and failure prompts, and the experience will be relatively smooth. This will indeed give some scientists who can use back-end code instructions an advantage, but it is essentially a problem on the wallet experience side and has nothing to do with the processing power of the zkSync chain.
2) Sequencer fair sorting link:When the user sends a transaction to the RPC queue for a short period of time, each transaction will be superimposed starting from the nonce value of 0. If the previous transaction is still in the queue, the nonce is 0. At this time, the user initiates a new transaction with the nonce value of 0. 1. The Sequencer of zkSync will assign nonces to these transactions based on time, and then sort them in order.
But if the user sees that the previous transaction failed in the previous stage of MetaMask, and then submits a new transaction at the same time,It is possible that some of the newly submitted transactions were not successfully submitted to the RPC queuing sequence due to issues with the wallet and zkSync API interface calls.The user thinks that a lot of transactions have been submitted, but in fact zkSync has only received a part of them, and as long as they receive it, it will be sorted and processed.
Looking at it this way, when users see MetaMask reporting transaction failures, the behavior of constantly submitting new transactions will also cause a large number of transaction failures.Because there is no submission to the backend of the zkSync chain at all, but you think you submitted it on the frontend.
Overall, the MetaMask wallets RPC response time logic issues and users behavior of rushing to add transactions to the chain will cause a large number of transaction failures.If you understand zkSyncs background transaction processing workflow, it is relatively easier to avoid these optimization experience problems.
-Based on the above popular science, let’s clarify the issue of “downtime”:
The zkSync chain is not down, it is just a browser front-end display problem, because the browser will pull the latest data through zkSyncs RPC interface, but the interface response will be delayed, and a large number of new transactions will slow down the response.
In short,The browsers pull data synchronization speed cannot keep up with the surge in queued transactions. This is a problem with the browser front end and has nothing to do with the operation of the chain.Usually the problem will be solved once the transaction speed slows down enough and the browser can crawl the new data.
When the browser does not work, you can cross-verify through other browsers that synchronize zkSync block data information, such as: https://hyperscan.xyz
-What is the operational performance of the real chain?
1) After the so-called downtime rumors broke out, zkSync’s official staff @anthonykrose frequently posted TPS refresh news on Twitter.In fact, zkSync TPS soared to a peak of 187.9. Under normal circumstances, TPS is only about 50-100, which shows that zkSync has actually withstood the pressure due to the influx of a large number of new transactions.This indeed provides a sufficient stress test for thousands or even tens of thousands of TPS in the future.
2) The special mechanism of ZK-Rollup determines that the larger the transaction volume processed, the cheaper the Gas fee. In fact, the Gas fee of zkSync is indeed cheaper because the transaction cost is also shared. According to growthepie data,In the past 24 hours, zkSyncs Gas average has dropped by 5.2%, averaging around $0.19. Everyones experience with this data may be different, but based on the comprehensive chains operating data, it is indeed cheaper.This proves that ZK-Rollup’s smoother experience requires increasing the existing user scale by an order of magnitude.
-What impact does the inscription incident have on the layer 2 public chain?
According to dune data, Syncs inscription casting has added 5M transactions in 14 hours, and 65,575 Holders have participated. As mentioned above, zkSync officials are aware of this community-initiated stress test activity and have taken urgent measures to ensure the orderly progress of the zkSync chain.
This data is indeed a better stress test experiment for zkSync, and its positive impact outweighs the negative.In the long run, the Inscription incident did not bring Layer 2 performance back to the prototype as rumored, but instead provided practical experience for further performance optimization of Layer 2.
However, as far as I know, in addition to Sync, there are other inscriptions being minted. Although not as fomo as Sync, they also add fuel to this stress test.
Anyway, the results are generally good. If you clarify the technical logic of zkSyncs background sorting and block generation, and then get rid of the misunderstanding of bad experience, you should understand that everything is running well, and we have to give layer 2 a little more confidence.
