Under the inscription stress test, zkSync completed a successful "open training"

Original Author: Haotian (X: @tmel0211)

Editor’s note: The inscription track is still hot, zkSync chain has been flooded with a huge number of transactions in a short period of time, in this “stress test”, zkSync is down because of the inscription, or has it been tested perfectly? Crypto researcher Haotian (X:@tmel0211) clarified the illusion and misunderstanding of zkSync’s “bad experience” from technical logic, and Odaily Planet Daily sorted it out as follows:

The inscription engraved on the zkSync chain and the short-term influx of sky-high transactions are indeed a “stress test” of the performance of the Layer 2 public chain, but the result is not a “downtime”, on the contrary, this is a @zksync public training, and the result is that the TPS peak, GAS stability, etc. have been perfectly tested. **

At first glance, doesn’t it sound a bit counterintuitive? Next, with technical logic, let me clarify it for you:

The working principle of zkSync packaging blocks is simply as follows: users construct transactions into the sorting sequence of zkSync Sequencer, and then Sequencer packs them into blocks according to the ranking of gas fees, and then passes the blocks to the Proof system for verification, and finally submits them to the mainnet to complete finality status confirmation. **

-There are 2 key points here, which are easy to create the illusion of “bad experience”:

1. Users construct transaction links: Most users will initiate transactions through wallets such as Metamask, and send transactions to zkSync through wallets, and the transactions will first enter the RPC remote call server, and then Sequencer will receive these transactions and enter the queued sequence. The queue time here can be as short as a few seconds or as long as a few minutes, and if you wait for a long time, MetaMask will assume that the transaction has failed, and then the front-end will return a message that the transaction has failed.

However, this does not mean that the transaction actually failed, but only because of the “incompatibility” between Metamask’s RPC response time and feedback logic and zkSync’s Sequencer queued package transaction logic. **This is the reason why some transactions that appear to be failed in MetaMask show success again after waiting for a while.

If the user does not go through the wallet pipeline and directly uses the backend code to call the RPC of zkSync, there will be no response time timeout and prompt failure, and the experience will be relatively smooth. This does give an advantage to some “scientists” who can use backend code instructions, 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 Ordering Session: When the user sends a transaction to the RPC queue for a short time, each transaction will be stacked from the nonce value of 0, if the previous transaction is still in the queue state, the nonce is 0, then the user initiates a new transaction with a nonce of 1, and the Sequencer of zkSync will assign a nonce to these transactions according to the time, and then sort them in order.

However, if the user submits a new transaction at the same time after seeing that the previous transaction failed in the previous section of MetaMask, it is likely that some of the newly submitted transactions will not be successfully submitted to the RPC queue due to the problem of the wallet side and the zkSync API interface call. Users think that a lot of transactions have been submitted, but in fact zkSync has only received a portion of them, and as soon as they receive them, they will sort them.

Looking at it this way, users see that MetaMask reports that transactions have failed, and the act 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 have submitted it on the frontend. **

Overall, MetaMask wallet’s RPC response time logic issues and users’ rush to overlay transactions on-chain will cause a large number of transaction “failures”, and it is relatively easier to avoid these optimization experience issues if you are clear about zkSync’s back-end transaction processing workflow.

-Based on the above popular science, let’s clarify the “downtime” problem:

The zkSync chain is not “down”, it is just a display problem on the front-end of the browser, because the browser will pull the latest data through the RPC interface of zkSync, but there will be a delay in the interface response, and a large number of new transactions will slow down the response.

In short, the speed of the browser’s pull data synchronization cannot keep up with the surge in queued transactions, which is a problem with the browser’s front-end and has nothing to do with the operation of the chain. **The problem is usually resolved when the transaction speed slows down appropriately and the browser can capture new data.

When the browser does not work, you can use other browsers that synchronize the zkSync block data information to cross-verify, such as:

-What is the “operational performance” of the real chain?

1. After the so-called outage rumors broke, zkSync’s official staff @anthonykrose tweeted TPS refreshes. In fact, zkSync TPS has soared to a peak of 187.9, and under normal circumstances, the TPS is only around 50-100, which indicates that there is a huge influx of new transactions, and zkSync has actually resisted the pressure. This does provide a full “stress test” for thousands, if not 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, the average gas of zkSync has also decreased by 5.2%, with an average of about $0.19, this data may not be the same for everyone, but the operation data of the integrated chain is indeed cheaper. **This proves that the smoother experience of ZK-Rollup requires an order of magnitude increase in the existing user scale.

-The impact of inscription events on layer 2 public chains?

According to dune data, Sync’s inscription minting has added 5 M transactions in 14 hours, and 65,575 Holders have participated. As mentioned above, zkSync officials are aware of this community-initiated “stress test” and are taking urgent steps to ensure that the zkSync chain runs in an orderly manner.

This data is indeed a good stress test experiment for zkSync, and its positive effects outweigh the negatives. **In the long run, the inscription incident did not rumore, but rather provided practical experience for further Layer 2 performance optimization. **

However, as far as I know, there are other inscriptions being minted besides Sync, which are not as fomo as Sync, but add fuel to the fire of this stress test.

Anyway, the results are generally good, if you clarify the technical logic of zkSync’s backend sorting blocks, and then get rid of the misunderstanding of “bad experience”, you should understand that everything is running well, and we need to give layer 2 a little more confidence.

Link to original article