Inscription mania is transmitted to Layer 2, why can zkSync pass the stress test of sky-high trading?

Written by: Haotian

The inscription engraved on the zkSync chain and the short-term influx of sky-high transactions is indeed a “stress test” of the performance of the layer2 public chain, but the result is not a “downtime”, on the contrary, this is a public training of zkSync, and the result is that the TPS peak and GAS stability 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 put: users construct transactions into the sorting sequence of zkSync Sequencer, and then Sequencer packs them into blocks according to the gas fee ranking, 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 that can easily create the illusion of a “bad experience”:

1. Users construct transactions: 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 queue 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 doesn’t mean that the transaction actually failed, but only because there is an “incompatibility” between Metamask’s RPC response time and feedback logic and zkSync’s Sequencer queuing and packing transaction logic. That’s why, after waiting for a while, the backend server shows that some transactions that MetaMask shows as failing.

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 link: when the user sends a transaction to the RPC queue for a short time, each transaction will be superimposed 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, 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 some 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 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 have submitted it on the frontend.

On the whole, the RPC response time logic of the MetaMask wallet and the user’s rush to overlay transactions on the chain will cause a large number of transaction “failures”, and it is relatively easy to avoid these optimization experience problems if you are clear about the background transaction processing workflow of zkSync.

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

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 speed of the proliferation of queued transactions, which is a problem with the browser’s front-end and has nothing to do with the operation of the chain. Usually, the problem will be solved when the transaction speed slows down appropriately and the browser can capture the 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, Anthony Rose, an official staff member of zkSync, frequently tweeted TPS refresh reports. 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 large influx of new transactions, and zkSync has actually resisted the pressure. This is indeed 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 apportioned, 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 needs to increase the existing user scale by an order of magnitude.

What is the impact of inscription events on layer2 public chains?

According to dune data, Sync’s inscription minting 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” 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 performance optimization of Layer 2.

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 backend sorting out blocks, and then get rid of the misunderstanding of “bad experience”, you should understand that everything is running well, and we have to give layer2 a little more confidence.