NewsFlash Articles Data Fundraising BlockBeats Pro

Why is it said that zkSync has successfully conducted "public training"?

Read this article in 10 Minutes

In the long run, the Mingwen incident did not send Layer2 performance back to its prototype as rumored, but instead provided practical experience for further performance optimization of Layer2.

The content you provided is:

Original author: Haotian

Editor's note: Recently, with the popularity of inscriptions, major public chains have seen a surge in transactions in a short period of time. This is undoubtedly a "big test" for public chains. In this test, zkSync has perfectly withstood the test in terms of TPS peak and GAS stability. Regarding this topic, encryption researcher Haotian has expressed his views from a technical perspective on x, and BlockBeats has compiled them as follows:

Engraving on zkSync chain, the short-term surge of massive transactions is indeed a "stress test" of Layer2 public chain performance, but the result is not a "crash", on the contrary, this is a public training of @zksync, and the results have perfectly withstood the test of TPS peak and GAS stability.

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

zkSync's block packaging works as follows: Users construct transactions that enter the sorting sequence of the zkSync Sequencer, which then sorts and packages them into blocks based on Gas Fee, and then passes the blocks into the Proof system for verification before submitting them to the main network for finality confirmation.

-There are 2 key points here, which can easily create the illusion of "poor experience":

1) User transaction construction: Most users initiate transactions through wallet interfaces such as Metamask. When a transaction is sent to zkSync through the wallet interface, it first enters the RPC remote call server and then the Sequencer receives these transactions and adds them to the queue. The queue time can range from a few seconds to several minutes. If the waiting time is too long, MetaMask will consider the transaction failed and the frontend will return a transaction failed prompt.

However, this does not mean that the transaction has truly failed, but rather because of the "incompatibility" between Metamask's RPC response time and feedback logic and zkSync's Sequencer queuing and packaging transaction logic. This is why some transactions that appear to have failed in MetaMask will show as successful on the backend server after waiting for a period of time.

If users do not use the wallet channel and directly call zkSync's RPC through backend code, there will be no issues with response time outs or failed prompts, resulting in a relatively smooth experience. This does give an advantage to some "scientists" who can use backend code commands, but fundamentally it is a problem with the wallet experience and not related to zkSync's processing capabilities.

2) Sequencer Fair Ordering: When a user sends a transaction to the RPC queue for a short time, each transaction will be stacked starting from nonce value 0. If the previous transaction is still in the queue with nonce 0 and the user initiates a new transaction with nonce 1, zkSync's Sequencer will allocate nonces to these transactions based on time and then sort them in order.

However, if a user sees a previous transaction fail on the MetaMask front end and submits a new transaction, it is highly likely that due to issues with the wallet and zkSync API interface calls, some of the new transactions were not successfully submitted to the RPC queue. The user may think they have submitted many transactions, but in reality, zkSync only received a portion of them, and as long as they receive them, they will be sorted and processed.

In this way, when users see MetaMask feedback on transaction failure and keep submitting new transactions, it will also cause a large number of transaction failures, because they were not actually submitted to the backend of the zkSync chain, but you thought you had submitted them on the frontend.

Overall, the RPC response time logic issues of the MetaMask wallet and the behavior of users impatiently stacking transactions on the chain can both cause a large number of transaction "failures". If you understand the backend transaction processing workflow of zkSync, it is relatively easier to avoid these optimization experience issues.

- Based on the above popular science, let's clarify the issue of "downtime":

zkSync chain did not "crash", it is just a display issue on the browser front-end. The browser pulls the latest data through zkSync's RPC interface, but the response may be delayed, causing slower response times with a large number of new transactions.

In short, the synchronization speed of data retrieval in browsers 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, when the transaction speed slows down appropriately and the browser can retrieve new data, the problem will be resolved.

When encountering a browser that does not work, you can cross-validate through other browsers that synchronize zkSync block data information, such as: https://hyperscan.xyz.

-What is the performance of the "real chain"?

1) After the so-called downtime rumors broke out, @anthonykrose, an official staff member of zkSync, frequently posted TPS refresh news on Twitter. In fact, the peak TPS of zkSync soared to 187.9, while under normal circumstances, TPS is only around 50-100. This indicates that a large number of new transactions have poured in, and zkSync has actually withstood the pressure. This has indeed provided a sufficient "stress test" for future thousands or even tens of thousands of TPS.

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 value of zkSync has decreased by 5.2%, averaging around $0.19. This data may vary for each individual, but the overall operating data of the chain does show that it has become cheaper. This supports the smoother experience of ZK-Rollup, which requires an increase in the existing user base by an order of magnitude.

-The impact of the Mingwen incident on Layer2 public chains?

According to data from Dune Analytics, the Inscription Casting of Sync added 5 million transactions in 14 hours, with 65,575 holders participating. As mentioned above, the zkSync team is aware of the community-initiated "stress test" and has taken urgent measures to ensure the orderly operation of the zkSync chain.

This data is indeed a good stress test experiment for zkSync, and its positive impact outweighs the negative.

In the long run, the Mingwen incident did not set back the performance of Layer2 as rumored, but instead provided practical experience for further performance optimization of Layer2.

However, as far as I know, in addition to Sync, there are other inscriptions being forged. Although they are not as fomo as Sync, they have also added fuel to this stress test.

Anyway, the overall result is good. If you can clarify the technical logic of zkSync's background block sorting and dispel the "bad experience" misunderstanding, you should understand that everything is running smoothly and we should have more confidence in layer2.