Dans le cadre du test de résistance d’inscription, zkSync a réussi une « formation ouverte »

Auteur original : Haotian (X : @tmel0211)

Note de l’éditeur : La piste d’inscription est toujours chaude, la chaîne zkSync a été inondée d’un grand nombre de transactions en peu de temps, dans ce « stress test », zkSync est en panne à cause de l’inscription, ou a-t-il été parfaitement testé ? Le chercheur en cryptographie Haotian (X :@tmel0211) a clarifié l’illusion et l’incompréhension de la « mauvaise expérience » de zkSync de la logique technique, et Odaily Planet Daily l’a triée comme suit :

L’inscription gravée sur la chaîne zkSync et l’afflux à court terme de transactions vertigineuses sont 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 @zksync, et le résultat est que le pic TPS, la stabilité du GAS, etc. 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 simplement le suivant : les utilisateurs construisent les 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 2 points clés ici, qui sont faciles à créer l’illusion d’une « mauvaise expérience »:

1. Les utilisateurs construisent des liens de transaction : 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 en 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 à cause de « l’incompatibilité » entre le temps de réponse RPC et la logique de rétroaction de Metamask et la logique de transaction de package en file d’attente du séquenceur de zkSync. **C’est la raison pour laquelle certaines transactions qui semblent avoir échoué dans MetaMask réussissent à nouveau après un certain temps d’attente.

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. Session de commande équitable du séquenceur : Lorsque l’utilisateur envoie une transaction à la file d’attente RPC pendant une courte période, chaque transaction sera empilée à partir de la valeur de nonce de 0, si la transaction précédente est toujours dans l’état de file d’attente, le nonce est 0, puis l’utilisateur initie une nouvelle transaction avec un nonce de 1, et 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 qu’une partie, 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 fait de 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 que vous l’avez soumis sur le frontend. **

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

-Sur la base de la science populaire 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 l’augmentation 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. **Le problème est généralement résolu lorsque la vitesse de transaction ralentit de manière appropriée et que le navigateur peut capturer de 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 :

-Quelle est la « performance opérationnelle » de la chaîne réelle ?

1. Après que les soi-disant rumeurs de panne aient éclaté, le personnel officiel de zkSync @anthonykrose tweeté des actualisations de 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 énorme afflux de nouvelles transactions, et zkSync a en fait résisté à la pression. Il s’agit d’un « test de résistance » complet 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 partagé, 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 nécessite une augmentation d’un ordre de grandeur de l’échelle d’utilisateurs existante.

-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 des blocs de tri backend de 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.

Lien vers l’article original