La manie de l’inscription est transmise à la couche 2, pourquoi zkSync peut-il passer le test de résistance du trading vertigineux ?

Écrit par : Haotian

L’inscription gravée sur la chaîne zkSync et l’afflux à court terme de transactions vertigineuses est en effet un « stress test » de la performance de la chaîne publique de couche 2, mais le résultat n’est pas un « temps d’arrêt », au contraire, il s’agit d’un entraînement public de zkSync, et le résultat est que le pic TPS et la stabilité du GAS ont été parfaitement testés.

À première vue, cela ne semble-t-il pas un peu contre-intuitif ? Ensuite, avec une logique technique, permettez-moi de clarifier les choses pour vous :

Le principe de fonctionnement des blocs d’empaquetage zkSync est simple : les utilisateurs construisent des transactions dans la séquence de tri de zkSync Sequencer, puis Sequencer les emballe dans des blocs en fonction du classement des frais de gaz, puis transmet les blocs au système Proof pour vérification, et enfin les soumet au réseau principal pour terminer la confirmation de l’état final.

Il y a ici 2 points clés qui peuvent facilement créer l’illusion d’une « mauvaise expérience » :

1. Les utilisateurs construisent des transactions : La plupart des utilisateurs initieront des transactions via des portefeuilles tels que Metamask, et enverront des transactions à zkSync via des portefeuilles, et les transactions entreront d’abord dans le serveur d’appel distant RPC, puis Sequencer recevra ces transactions et entrera dans la séquence de file d’attente. Le temps d’attente ici peut être aussi court que quelques secondes ou aussi long que quelques minutes, et si vous attendez longtemps, MetaMask supposera que la transaction a échoué, puis le front-end renverra un message indiquant que la transaction a échoué.

Cependant, cela ne signifie pas que la transaction a réellement échoué, mais seulement parce qu’il y a une « incompatibilité » entre le temps de réponse RPC et la logique de rétroaction de Metamask et la logique de transaction de mise en file d’attente et d’empaquetage du séquenceur de zkSync. C’est pourquoi, après avoir attendu un certain temps, le serveur backend affiche que certaines transactions que MetaMask affiche comme ayant échoué.

Si l’utilisateur ne passe pas par le pipeline du portefeuille et utilise directement le code backend pour appeler le RPC de zkSync, il n’y aura pas de délai d’expiration du temps de réponse ni d’échec de l’invite, et l’expérience sera relativement fluide. Cela donne un avantage à certains « scientifiques » qui peuvent utiliser les instructions de code backend, mais c’est essentiellement un problème du côté de l’expérience du portefeuille et n’a rien à voir avec la puissance de traitement de la chaîne zkSync.

2. Lien d’ordre équitable du séquenceur : lorsque l’utilisateur envoie une transaction à la file d’attente RPC pendant une courte période, chaque transaction sera superposée à partir de la valeur du nonce de 0, si la transaction précédente est toujours dans l’état de la file d’attente, le nonce est 0, puis l’utilisateur initie une nouvelle transaction avec un nonce de 1, le séquenceur de zkSync attribuera un nonce à ces transactions en fonction de l’heure, puis les triera dans l’ordre.

Cependant, si l’utilisateur soumet une nouvelle transaction en même temps après avoir constaté que la transaction précédente a échoué dans la section précédente de MetaMask, il est probable que certaines des transactions nouvellement soumises ne seront pas soumises avec succès à la file d’attente RPC en raison du problème du côté portefeuille et de l’appel de l’interface de l’API zkSync. Les utilisateurs pensent que beaucoup de transactions ont été soumises, mais en fait zkSync n’en a reçu que quelques-unes, et dès qu’ils les recevront, ils les trieront.

En regardant les choses de cette façon, les utilisateurs voient que MetaMask signale que les transactions ont échoué, et le comportement consistant à soumettre constamment de nouvelles transactions entraînera également un grand nombre d’échecs de transaction, car il n’y a pas du tout de soumission au backend de la chaîne zkSync, mais vous pensez l’avoir soumise sur le frontend.

Dans l’ensemble, la logique de temps de réponse RPC du portefeuille MetaMask et la précipitation de l’utilisateur à superposer les transactions sur la chaîne entraîneront un grand nombre d’échecs de transaction, et il est relativement facile d’éviter ces problèmes d’expérience d’optimisation si vous êtes clair sur le flux de travail de traitement des transactions en arrière-plan de zkSync.

Sur la base de la vulgarisation scientifique ci-dessus, clarifions le problème des « temps d’arrêt » :

La chaîne zkSync n’est pas « en panne », c’est juste un problème d’affichage sur le front-end du navigateur, car le navigateur va extraire les dernières données via l’interface RPC de zkSync, mais il y aura un retard dans la réponse de l’interface, et un grand nombre de nouvelles transactions ralentira la réponse.

En bref, la vitesse de synchronisation des données d’extraction du navigateur ne peut pas suivre la vitesse de la prolifération des transactions en file d’attente, ce qui est un problème avec le front-end du navigateur et n’a rien à voir avec le fonctionnement de la chaîne. Habituellement, le problème sera résolu lorsque la vitesse de transaction ralentira de manière appropriée et que le navigateur pourra capturer les nouvelles données.

Lorsque le navigateur ne fonctionne pas, vous pouvez utiliser d’autres navigateurs qui synchronisent les informations de données de bloc zkSync pour effectuer des vérifications croisées, telles que :

Qu’est-ce que la « performance opérationnelle » de la chaîne réelle ?

1. Après que les soi-disant rumeurs de panne aient éclaté, Anthony Rose, un membre officiel du personnel de zkSync, a fréquemment tweeté des rapports d’actualisation du TPS. En fait, zkSync TPS a atteint un pic de 187,9, et dans des circonstances normales, le TPS n’est que d’environ 50-100, ce qui indique qu’il y a un afflux important de nouvelles transactions, et zkSync a en fait résisté à la pression. Il s’agit en effet d’un « test de résistance » suffisant pour des milliers, voire des dizaines de milliers de TPS à l’avenir.

2. Le mécanisme spécial de ZK-Rollup détermine que plus le volume de transaction traité est important, moins les frais de gaz sont chers, en fait, les frais de gaz de zkSync sont en effet moins chers, car le coût de transaction est également réparti, selon les données de growthepie, au cours des dernières 24 heures, le gaz moyen de zkSync a également diminué de 5,2%, avec une moyenne d’environ 0,19 $, ces données ne sont peut-être pas les mêmes pour tout le monde, mais les données de fonctionnement de la chaîne intégrée sont en effet moins chères. Cela prouve que l’expérience plus fluide de ZK-Rollup doit augmenter l’échelle d’utilisateurs existante d’un ordre de grandeur.

Quel est l’impact des événements d’inscription sur les chaînes publiques de couche 2 ?

Selon les données des dunes, la frappe d’inscription de Sync a ajouté 5 millions de transactions en 14 heures, et 65 575 détenteurs y ont participé. Comme mentionné ci-dessus, les responsables de zkSync sont au courant de ce « test de résistance » initié par la communauté et prennent des mesures urgentes pour s’assurer que la chaîne zkSync fonctionne de manière ordonnée.

Ces données sont en effet une bonne expérience de test de résistance pour zkSync, et ses effets positifs l’emportent sur les effets négatifs. À long terme, l’incident de l’inscription n’a pas fait l’objet d’une rumeur, mais a plutôt fourni une expérience pratique pour une optimisation plus poussée des performances de la couche 2.

Cependant, pour autant que je sache, il y a d’autres inscriptions en cours de frappe en plus de Sync, qui ne sont pas aussi fomo que Sync, mais qui ajoutent de l’huile sur le feu de ce test de résistance.

Quoi qu’il en soit, les résultats sont généralement bons, si vous clarifiez la logique technique du tri des blocs par le backend zkSync, puis que vous vous débarrassez du malentendu de « mauvaise expérience », vous devriez comprendre que tout fonctionne bien, et que nous devons donner un peu plus de confiance à la couche 2.