Analyse approfondie : comment Solana a-t-elle été bloquée ?

Pourquoi les transactions en cours sur Solana échouent-elles toujours ?

Analysons-le étape par étape en partant des concepts les plus élémentaires.

Du point de vue de l'utilisateur, lorsque nous négocions sur Solana, il y a essentiellement trois résultats potentiels :

• La transaction est exécutée avec succès et tout va bien

• L'exécution de la transaction a échoué ; . L'utilisateur a payé les frais de gaz, mais le résultat de l'exécution a été renvoyé de manière incorrecte. Cela se produit lorsque les conditions d'une transaction ne sont pas remplies, comme par exemple que le token que l'utilisateur tente d'acheter est épuisé, ou que le prix fluctue trop rapidement (au-delà du glissement prédéfini), etc. transaction (Abandonné)

   : La transaction n'a aucune trace, c'est-à-dire qu'elle n'a pas réussi à atteindre le "nœud leader du bloc" (Remarque Odaily : le nœud de service qui tourne tous les 4 blocs).
C'est la situation à laquelle la plupart des utilisateurs sont actuellement confrontés. Il s'agit essentiellement d'un problème de couche réseau, et non d'un problème de couche consensus ou de couche d'exécution.

• Les problèmes d'exécution ne sont pas la principale cause de congestion

Maintenant, vous vous demandez peut-être quelle est la couche réseau ?

Pourquoi les transactions sont-elles perdues ? Pourquoi sont-ils la principale cause de la congestion actuelle à Solana ?

Laissons de côté ces problèmes les plus importants pour le moment, et examinons d'abord les transactions qui n'ont pas pu être exécutées (c'est-à-dire le deuxième cas), et expliquons pourquoi les transactions échouées ne sont pas la principale cause de congestion.

Combinés aux données en chaîne, on peut voir que seulement environ 8 % de toutes les transactions ayant échoué ont été soumises par de vrais utilisateurs, et le reste étaient des transactions d'arbitrage initiées par des robots en chaîne.

La raison pour laquelle les arbitragistes continuent d'initier des transactions « indésirables » est que le coût du lancement fréquent de transactions peut être considéré comme minime par rapport aux bénéfices potentiels qui peuvent être obtenus grâce à un arbitrage réussi.

Plus précisément, les arbitragistes peuvent lancer des transactions en continu au cours d'une journée. Le coût pour cela est d'environ quelques centaines de dollars par jour (car les frais de réseau de Solana sont faibles), mais tant qu'ils réussissent, ils peuvent réaliser des bénéfices. des bénéfices se chiffrant en centaines de milliers de dollars.

Il convient de noter que ces transactions échouées ne signifient pas que le réseau Solana est en panne et que la blockchain fonctionne toujours normalement. Ce ne sont que quelques transactions robotisées qui ont échoué parce que les conditions n'étaient pas remplies.

Ce n’est pas la raison principale de la mauvaise expérience actuelle de Solana.

En fait,

Le taux d'échec des transactions de Solana est resté à environ 50 % depuis novembre de l'année dernière.

La vraie cause : les transactions abandonnées au niveau de la couche réseau

Maintenant, discutons de la véritable cause de la congestion de Solana au cours des derniers jours – les « transactions perdues ».

Comme mentionné précédemment, ce sont des transactions qui n'ont pas réussi à atteindre le « nœud leader du bloc », et la raison pour laquelle les transactions n'ont pas réussi à arriver est parce qu'elles ont été rejetées dans la couche réseau.

La couche réseau est la couche de communication d'Internet. Elle est utilisée pour envoyer des paquets de données d'un point de terminaison à un autre. Les protocoles courants de la couche réseau incluent TCP, UDP, QUIC (développés par Google), etc. Solana a précédemment mis à niveau son protocole de couche réseau vers QUIC, Cela permet d'établir des connexions entre les utilisateurs et les « nœuds leaders de bloc ».

Étant donné que Solana adopte un mécanisme de génération de blocs continu et qu'il n'y a pas de pool de mémoire pour stocker temporairement les transactions non confirmées, cela signifie qu'une fois la connexion perdue, la transaction ne sera plus jamais incluse dans un bloc.

L'avantage du protocole QUIC est que le "block leader node" peut obtenir une nouvelle fonction : Couper les connexions de certains utilisateurs ou limiter leur débit de transfert de données en fonction de critères précis.

L'importance de cette fonctionnalité est que lorsque la demande maximale du réseau se produit, le « nœud leader du bloc » peut couper de manière proactive certaines connexions, empêchant ainsi Solana de s'arrêter complètement en raison d'une activité réseau accrue.

Vous vous demandez peut-être encore une fois, si la conception du protocole QUIC est si parfaite, pourquoi Solana est-elle toujours aussi bloquée maintenant ?

Le vrai problème est que même si les « nœuds leaders de bloc » peuvent désormais choisir de réguler activement certaines connexions, la logique permettant de décider quelles connexions doivent être régulées est problématique.

Afin de comprendre ce problème plus concrètement, on peut imaginer une situation où chaque "nœud leader de bloc" dispose de X connexions pouvant communiquer, mais lorsque le pic de demande du réseau survient à ce moment-là, les demandes de connexion reçues par le nœud sont 10 à 100 fois sa capacité de charge... A ce moment, le nœud doit choisir de couper certaines connexions. Cependant, la situation actuelle est qu'il n'existe pas de norme définie sur la manière de sélectionner les connexions à couper (comme couper toutes les connexions dont le coût est inférieur à xxx), et la question de savoir si toutes les connexions seront coupées est aléatoire. .. En fin de compte, dans la situation actuelle si vous souhaitez qu'une transaction soit confirmée, tout ce que vous pouvez faire est d'envoyer plus de demandes de transaction, mais comme il existe de nombreux robots qui enverront aussi constamment un grand nombre de demandes de connexion au réseau, les utilisateurs ordinaires établissent une connexion et le trading complet devient de plus en plus difficile.

Comment réparer ? le temps qu'il faut?

C'est le problème auquel Solana est confrontée actuellement.

Actuellement, Jump (équipe de développement client Firedancer), Anza (équipe de développement client Agave), Solana Labs et d'autres équipes

travaillent sur la réparation de la couche réseau. Les correctifs seront déployés progressivement cette semaine et des mises à jour importantes devraient être publiées dans les semaines à venir.

Est-ce que cela résoudra efficacement le problème ? Solana va-t-elle encore "sur la lune"... il n'y a pas de réponse absolue.

Il existe encore de nombreuses incertitudes pour trois raisons principales :

• Premièrement, personne ne peut garantir que le prochain patch de réparation prendra effet. Ce n’est qu’une fois que cela a réellement fonctionné que nous pouvons voir ce qui se passe réellement.

• Deuxièmement, le client Firedancer développé par Jump semble pouvoir résoudre le problème, mais il ne sera officiellement publié qu'à la fin de cette année.

• Le troisième problème concerne les transactions « indésirables » Le mécanisme économique de Solana rend difficile pour le réseau d'empêcher des acteurs malveillants de continuer à mener des attaques de transactions « indésirables » sur la chaîne.

Enfin, je veux appeler tout le monde à réaliser une chose : je crois que Solana se bat pour faire les bons compromis (Remarque Odaily : fait référence à l'établissement de normes raisonnables de segmentation des connexions), tout comme Ethereum Solana le sera. libre de ces problèmes, comme elle l'a été de tant d'autres.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!