Did the Byzantine fault cause zkSync network crash? Why are core developers celebrating the technical breakthrough instead?

The first token minting project, Sync, in the zkSync ecosystem opened for minting on the 17th. However, on that day, the blockchain browser displayed anomalies and some users experienced frequent transaction failures, leading to widespread belief that the zkSync Era network was down. Cryptocurrency researcher Haotian, however, presented a different perspective, stating that the network was operating normally and not experiencing the issues as misunderstood by the public.

Did the NFT Craze Cause zkSync to Crash?

The NFT frenzy has spread to zkSync, where the first NFT project, Sync, was launched on the 17th, open for everyone to mint. The project is expected to open a marketplace and minting services in the future.

However, on the same day, zkSync encountered a crisis as a large number of transactions flooded in within a short period of time. The blockchain browser displayed abnormalities, and some users' wallet transactions failed frequently. The community briefly believed that zkSync had been paralyzed due to the NFT minting.

zkSync Actually Functioning Normally

Following the incident, zkSync developer Anthony Rose stated on Twitter that the network was not down but operating normally, with TPS even exceeding usual performance. So why did participating users face the aforementioned issues? Cryptocurrency researcher Haotian provided some explanations, suggesting that this incident actually showcased zkSync's efficiency and flexibility.

Discrepancy in Design between Metamask and zkSync

Firstly, it is important to understand how zkSync block creation works. In the zkSync network, after users sign a transaction, the transaction information is sent to the sequencer, where it is sorted and packed into blocks based on gas fees. The block proof information is then chained to the Ethereum mainnet for final confirmation.

Most users sign transactions through wallets like Metamask, and the sequencer receives the transaction information, entering a waiting state for sorting and packing. The waiting time can range from seconds to minutes. If the wait is long, Metamask's internal mechanism may deem the transaction failed, resulting in a frontend display of a failed transaction.

This does not mean the transaction actually failed; it is due to a discrepancy between Metamask's RPC feedback logic and zkSync's sequencer queuing and packing logic. This is why some transactions that Metamask shows as failed may eventually succeed after a waiting period, as the backend server displays. If users do not use wallets and directly call zkSync's RPC through backend code, they will not encounter timeout responses and failure prompts.

Therefore, the transaction failures in this incident are related to wallet experience on the frontend and not to zkSync network processing capabilities.

Multiple Simultaneous Transaction Submissions Causing API Invocation Errors

The sorting based on transaction gas fees by the sequencer may also lead to user misunderstandings.

When a user initiates a transaction, each transaction starts from a nonce value of 0. If a transaction is still queued and the user initiates a new transaction with a nonce value of 1, the new transaction must wait for the completion and successful block packing of the nonce 0 transaction before executing the nonce 1 transaction.

It is speculated that when users saw the previous transaction fail on Metamask and simultaneously submitted a new transaction, some of the new transactions may not have been successfully added to the RPC waiting queue due to wallet-side and zkSync API call issues. This could have caused some transactions to be skipped due to overlapping nonce values. In reality, zkSync's mainnet only received partial transaction information.

Therefore, the RPC response time logic issue with Metamask wallet and users hastily stacking transactions on the chain can lead to a high volume of transaction failures.

Blockchain Browser RPC Interface Delays

Regarding the abnormality in the blockchain browser, Haotian mentioned that zkSync network did not crash; it was just the frontend of the blockchain browser displaying anomalies. Since the browser also needs to read the latest data through zkSync's RPC interface, response delays due to a high volume of transactions may cause abnormal browser displays.

Ultimately, when the blockchain browser fails, users can cross-verify by using other browsers that sync zkSync block data, such as https://hyperscan.xyz

How Is zkSync's Actual Performance?

Despite rumors of a crash, zkSync's official representative @anthonykrose frequently posted TPS updates on Twitter. zkSync's TPS peaked at 187.9, while under normal circumstances, TPS is around 50 to 100, indicating that despite the influx of new transactions, zkSync network managed the pressure well.

This incident indeed served as a comprehensive "stress test" for future thousands or even tens of thousands of TPS.

On the other hand, ZK-Rollup has a special mechanism where the larger the transaction volume, the cheaper the gas fees. By spreading the cost of zero-knowledge proof on-chain across more transactions, zkSync's gas fees are indeed cheaper currently.

According to growthepie data, zkSync's average gas fee decreased by 5.2% to an average of around $0.19, confirming that ZK-Rollup can provide a better user experience as user numbers increase in the future.

NFTs Bringing Stress Testing to Layer2

According to Dune data, the launch of the Sync NFT minting added five million transactions on that day, with 65,575 users participating. In essence, it was indeed an effective stress test.

Understanding the underlying technical principles will reveal that zkSync actually performed well. The NFT event did not revert Layer2 performance as rumored but allowed the team to further optimize performance based on market experience, moving away from TPS measurements in experimental environments. In the long run, this will lead to a healthier industry development.

Haotian believes that more confidence should be placed in Layer2 solutions.